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Preface 



This volume contains the proceedings of the Fourth IFIP WG 6.1 Inter- 
national Conference on Formal Methods for Open Object-Based Distributed 
Systems (FMOODSOO). The conference was held in Stanford, California, on 
September 6-8, 2000. The event was the fourth meeting of this conference 
series, initiated in Paris in March 1996. 

The goal of the FMOODS series of conferences is to bring together re- 
searchers whose work encompasses three important and related fields: 

■ formal methods, 

■ distributed systems, and 

■ object-based technology. 

Such a convergence is representative of some of the latest advances in the 
field of distributed systems and provides links between several scientific and 
technological communities (for instance, FORTE/PSTV, ICODP, ECOOP, etc.). 

The papers included in this book, which were presented at the conference, 
reflect the scope of the conference. The collection includes abstracts or papers 
of several invited talks, and papers that were submitted, reviewed, and accepted 
by the Program Committee. 

Invited Speakers 

We were fortunate to have the following invited speakers at FMOODS 2000: 



■ Roberto Gorrieri is Professor of Computer Science at the Universty of 
Bologna. His research interests include: theory of concurrency and co- 
ordination, formal methods and security.He is member of the executive 
board of EATCS, secretary of IFIP Technical Committee 1, and chair of 
IFIP WG 1.7 on foundations of security analysis and design. 

■ Jose Meseguer is a Principal Scientist at SRI International in Menlo Park, 
California. His reaserch interests include logic and semantics in com- 
puter science, formal methods, programming languages, and concurrent 
computing. 

■ Jayadev Misra is a professor and holder of the Regents’ chair in the De- 
partment of Computer Sciences at the Univ. of Texas at Austin. His 




X 



research interests are in the area of concurrent programming, with em- 
phasis on rigorous methods to improve the programming process. Misra 
is a fellow of ACM and IEEE; he held the Guggenheim fellowship during 
1988-1989. 

■ Alan Karp is a Department Scientist in the Decision Technology Depart- 
ment at HP Labs where he is conducting research in economic models 
for Internet economies. Before that, he was Senior Technical Contributor 
and Chief Scientist at Hewlett-Packard’s E-speak Operation, the group 
responsible for bringing HP’s e-speak technology to market. He was one 
of the architects of the HP/Intel iA64 processor. 

The technical papers in this volume include 16 papers that were selected 
among 33 submissions. The conference was partitioned in several sessions cov- 
ering formal methods related to the following topics: mobility, Java and UML, 
refinement and subtyping, temporal and probablistic properties, and compo- 
nents. 

The conference is sponsered by IFIP, in particular TC 6 and WG6.1, and 
thanks are due to Guy Leduc for his advice and support in this respect. 

We would like to thank the authors for their high quality submissions. We 
are very grateful to the program committee members and external referees for 
all their efforts in reviewing papers. 



Scott Smith and Carolyn Talcott 
Baltimore and Stanford 
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INVITED TALK 




ON THE SEMANTICS OF JAVASPACES 



Nadia Busi Roberto Gorrieri Gianluigi Zavattaro 
Dipartimento di Scienze delVlnformazione, Universitd di Bologna, 
Mura Anteo Zamboni 7, 1-40127 Bologna, Italy. 
busi, gorrieri, zavattar@cs.unibo.it 



Abstract JavaSpaces is a coordination middleware for distributed Java programming re- 
cently proposed by Sun Microsystems. It is inspired by the Linda coordination 
model: processes interact via the output {write), consumption {take), test for 
presence {read) and the test for absence {takelfExists and readIfExists) of data 
inside a shared repository. Three are the most interesting new features introduced 
by JavaSpaces. The first one is an event notification mechanism {notify): a pro- 
cess can register interest in the incoming arrivals of a particular kind of data, and 
then receive communication of the occurrence of these events. The second feature 
is the so-called distributed leasing: at the moment a client outputs a tuple, it also 
declares its required lifetime (that the server may satisfy only partially). The third 
feature is a timeout on the blocking operation of input: if no instance is found 
before the timeout expires, then the operation fails and terminates. We present 
a structured operational semantics for a process algebra featuring these coordi- 
nation primitives. This abstract semantics is used to clarify possible ambiguities 
of the informal definitions of JavaSpaces, to discuss possible implementation 
choices and to compare the expressive power of the new primitives. Interestingly 
enough, many subtle phenomena occur, some of which might lead to reconsider 
the actual choice of primitives. 



1. INTRODUCTION 

Coordination middlewares are emerging as suitable architectures for mak- 
ing easier the programming of distributed applications. JavaSpaces [15] and 
TSpaces [17], produced by Sun Microsystem and IBM respectively, are the 
most prominent proposals; they are both based on the shared dataspace coordi- 
nation architecture, originally proposed in Linda (see, e.g., [9]). The basic idea 
behind Linda is the so-called generative communication', its main features are 
the following: 

■ Asynchronous communication: it is realized by means of a (conceptually 
shared) communication medium (called tuple space) that is the actual 
place where all messages/tuples are delivered and extracted by the pro- 
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cesses. A sender may proceed just after performing the insertion of the 
tuple in the tuple space, while the receiver can remove the tuple at any 
time after that tuple is in the tuple space. Hence, the asynchronous com- 
munication between the sender and the receiver is realized by means of 
two synchronous operations with the tuple space. 

■ Read operation', a process can check the presence of some tuple, without 
removing it from the space. 

■ Conditional input/read predicates', these are non-blocking variants of 
the remove and read operations; if the required message is absent, the 
process is not blocked and continues with a different alternative. 

More recent extensions of the Linda paradigm (e.g., JavaSpaces and TSpaces) 
include some new primitives useful for coordination of complex applications in 
open, large, distributed systems. In this paper we will focus on some of them: 

■ Event notification. Besides the data-driven coordination typical of Linda, 
it may be very useful to include in a language an event-driven mechanism 
of process activation. A process can register its interest in future arrivals 
of some objects and then receive co mm unication of each occurrence of 
this event. 

■ Blocking operations with timeouts. The operations of removal or reading 
of an object can be weakened by expressing the deadline beyond which 
the operation fails. 

■ Guaranteed duration of service. An object inserted in the dataspace as 
well as the interest in an event notification need not to hold forever; in 
many cases it is useful that the language has the capability to declare time 
bounds on these operations, and even better to re-negotiate such bounds 
if needed. 

Despite of the clear relevance of such primitives for coordination middle- 
wares, very little has been done to define formally their semantics. One may 
think that formalizing the intended semantics of these primitives is superfluous, 
as their semantics could appear obvious. Unfortunately, this is not the case. In 
places, the informal definition of these primitives in the available documenta- 
tion is quite ambiguous (e.g., variants of the same primitives exist in different 
languages and even in the same language); this may have the effect of giving 
too much freedom in the implementation choices, hence producing semanti- 
cally different implementations. Moreover, awareness of the expressiveness 
capabilities of the various primitives is often lacking, as well as methods for 
reasoning about programs written with these primitives. 
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The standard approach to solve the problems above is to give a formal se- 
mantics to the coordination language of interest. Such a semantics would fix 
the actual interpretation of the primitives, can be a precise guide for the im- 
plementor as well as a tool for reasoning about language expressiveness and 
program properties. For example, in [2] we have presented two alternative 
formal semantics for a Linda-based process calculus related to two possible 
interpretations of the output operations. In the first interpretation, called or- 
dered, the processes are synchronous with the tuple space, while in the second 
one, called unordered, they are considered asynchronous. We have proved an 
interesting gap of expressiveness between the two interpretations showing that 
the calculus is Turing powerful under the ordered interpretation while this is not 
the case under the unordered one. Another interesting phenomenon is that this 
discrimination result holds only in the presence of test for absence operators; 
indeed, the calculus with only output, input, and read operations is not Turing 
powerful neither under the ordered interpretation. 

In [6] we have initiated an investigation about the semantics of languages 
like JavaSpaces and TSpaces, by abstracting the coordination primitives away 
from the concrete language. To this aim, we use the mathematical machinery 
developed by the process algebra community (see, e.g., [13, 11]) that seems 
flexible enough to be useful for our aims. The approach adopted is to the 
following: we have started from a Linda-based process calculus and the we 
extend it with the new primitives sketched above: event notification, timeouts 
on blocking operations, leasing for timing service requests. 

In this paper we report (simplified versions of) the process calculi presented 
in [6]. In addition to [6], we discuss for each of the extensions interesting 
subtle phenomena which occur when alternative interpretations of the seman- 
tics are considered. The alternative interpretations are of two kinds: ordered 
v.s. unordered interpretation for the output operation, and synchronous v.s. 
asynchronous interpretation for the passing of time. 

2. THE KERNEL LANGUAGE 

In this section we introduce the syntax and the operational semantics of a 
calculus comprising the basic Linda-like coordination primitives. It is a small 
variant of a previous calculus formerly presented in [1]. 

Let Name be a denumerable set of object types ranged over by a, 6, . . ., and 
Const be a set of program constants ranged over by K, K' , 

Let Conf (ranged over by P, Q, . . ., possibly indexed) be the set of the 
possible configurations defined by the following grammar: 

P ::= (a) I C I P\P 
C ::= 0 I p.C I T]1C.C \ C\C \ K 



where: 
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( 1 ) 

(3) 

(5) 

(7) 

(9) 

( 11 ) 



( a )^0 
take{a).P P 
take3(a)?P.Q P 

read3{a)lP. Q P 

P ^ P' Q Q' 

P\Q ^P'\Q' 



( 2 ) 

(4) 

( 6 ) 

(8) 

(10) 



P P' 

a ^ 

P\Q^P’\Q 



—<a, a, 



( 12 ) 



(13) 




write{a).P — ^ («)|-P 
read{a).P P 
take3{a)lP.Q ^ Q 
read3{a)lP. Q ^ Q 
P-^P' Q-^Q' 
P\Q-1^P\Q' 

P ^P' Q 
P\Q ^ P'\Q 
P 



Table 1 Operational semantics (symmetric rules omitted). 



fjL ::= write{a) \ read{a) | take{a) 

T) ::= read3{a) | take3{a) 

Programs are represented by terms C containing the coordination primitives; 
the dataspace is modeled by representing each of its objects a with a term (a). 
A configuration is composed of some programs and some available objects 
composed in parallel using the composition operator |. A program can be a 
terminated program 0 (which is usually omitted for the sake of simplicity), 
a prefix form fi.P, an if- then- else form rp.P-Q, the parallel composition of 
subprograms, or a program constant K. 

A prefix /i can be one of the primitives write{a), which introduces a new 
object (a) inside the data repository, read {a), which tests for the presence of an 
instance of object (a), and take (a), which consumes an instance of object (a). 
The last two primitives are blocking, in the sense that a program performing 
one of them cannot proceed until the operation is successfully completed. 

The guards of the if-then-else forms are read3{a) and take3{a), which are 
the non-blocking variants of read (a) and take (a), respectively. The notation 
is inspired by the similar operations readIfExists and takelfExists of JavaS- 
paces [15]. Their behaviour is represented by using terms having two possible 
continuations, e.g., read3(a)?P_ Q. The first continuation P is chosen if the 
requested object is available in the data repository; in this case the non-blocking 
operations behave exactly as the corresponding blocking ones. On the other 
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hand, if no instance of the requested object is actually available, the second 
continuation Q is chosen and the data repository is left unchanged. 

Constants are used to permit the definition of programs with infinite be- 
haviours. We assume that each constant K is equipped with one and only one 
definition K = (7; as usual we assume also that only guarded recursion is 
used [13]. 

The semantics of the language is described via a labeled transition system 
{Conf, Label, — >■) where Label = {r} U {a, a, a, -la | a G Name} (ranged 
over by a, /5, . . .) is the set of the possible labels. The labeled transition relation 
— > is the smallest one satisfying the axioms and rules in Table 1. For the sake 
of simplicity we have omitted the symmetric rules of (9) — (12). 

Axiom (1) indicates that (a) is able to give its contents to the environment by 
performing an action labeled with a. Axiom (2) describes the output operation: 
in one step a new object is produced. Axiom (3) associates to the action 
performed by the prefix in (a) a label a, the complementary of ¥, while axiom 
(4) associates to a read (a) prefix a label a. 

Axioms(5)and(6)describethesemanticsofiaA:e3(a)?P_ Q: if the required 
(a) is present it can be consumed (axiom (5)), otherwise, in the case (a) is 
not available, its absence is guessed by performing an action labeled with -la 
(axiom (6)). Axioms (7) and (8) are the corresponding axioms for the read3{a) 
operator; the unique difference is that the label a is used instead of a. 

Rule (9) is the usual synchronization rule; while rule (10) deals with the 
new label a representing a non-consuming operation: in this case the term 
performing the output operation (labeled with a) is left unchanged as the read 
operation does not consume the tested object. 

Rule (11) is the usual local rule, which is valid only for labels different from 
-I a; indeed, an action of this kind can be performed only if no object (a) is 
available in the data repository, i.e., no actions labeled with "d can be performed 
by the terms in the environment (rule (12)). The side condition of rule (11) 
considers also labels that will be defined in the following sections. 

Thelastrule(13) allowsaprogramconstant iiT definedbyiT = Ctoperform 
the same actions permitted to C. 

Note that rule (12) uses a negative premise; however, the operational se- 
mantics is well defined, because the transition system specification is strictly 
stratifiable [10], condition that ensures (as proved in [10]) the existence of a 
unique transition system agreeing with it. 

Reduction steps are those transformations which a configuration may have 
when considered stand-alone, in other words, without environment. Opera- 
tionally, we denote reductions with P — > P' defined as follows: 

P — >P' if and only if P ^ P' or P ^ P' or P ^ P' or P ^ P' 
where the last two labels will be discussed in the following. 




8 



We denote by P t the fact that P may give rise to an infinite sequence of 
reduction steps, and by P | the fact that P has a finite sequence of reduction 
steps leading to a configuration without outgoing reductions. 

2.1. ORDERED V.S. UNORDERED INTERPRETATION 
OF THE OUTPUT OPERATION 

The semantics that we have defined assumes that the programs are syn- 
chronous with the dataspace, in the sense that the emitted object is surely al- 
ready available inside the data repository at the moment the write operation 
terminates (see rule (2)). In a previous paper on the semantics of Linda [3], this 
kind of semantics is called ordered and alternative interpretations are presented, 
among which the unordered one which assumes that programs are asynchronous 
with the dataspace: the emitted object becomes available after an unpredictable 
delay. Operationally, the unordered semantics is modeled by substituting the 
rule (2) with the two following; 

(2') write{a).P ^ {{a))\P (2") {(a)) (a) 

Let Lo[wrt] and the calculus without the read3 and take3 primitives 

interpreted under the ordered and unordered interpretations, respectively; let 
Lo [wrt3] and [wrt3] be the calculi interpreted under the two interpretations. 

The paper [2] shows the existence of an expressiveness gap between these 
two alternatives. More precisely, adopting the result to the actual setting, we 
have that Lo[wrt], Lu[wrt], and Lu[wrt3] are not Turing powerful as P f and 
P 4- are decidable; on the other hand, Lg [wrf 3] is Turing powerful and P t and 
P 4- are both undecidable. 

The decidability results are proved by resorting to a finite Place/Transition 
net semantics (a formalism in which termination and divergence are decidable), 
while the undecidability results are consequence of the fact that it is possible 
to encode Random Access Machines (RAM), which is a well known register 
based Turing powerful formalism, into the considered language. 

3. EVENT NOTIFICATION 

In this section we extend the previous calculus with an event notification 
mechanism inspired by the notify primitive of JavaSpaces [15]. 

The syntax of the kernel language is simply extended by permitting a new 
prefix: 

fj, ... I notify{a, C) 

A program notify{a, C).P can register its interest in the future incoming ar- 
rivals of the data of kind a, and then receive communication of each occur- 
rence of this event. This behaviour can be modeled by introducing a new term 
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(14) 

(16) 

(18) 



(2') write{a).P (o)l-P 

notify{a,Q).P on{a,Q)\P (15) on{a,P) P\on{a,P) 



P-^P' Q Q' 
P\Q^P'\Q' 
P-^P' Q^Q' 



P\Q-^P'\Q' 



(17) 

(19) 



P P' Q 
P\Q -4 P'\Q 
P ^P' Q 4^ 
P\Q^P'\Q 



Table 2 Operational semantics of notify (symmetric rules omitted). 



on(a, C) (that we add to the syntax as an auxiliary term) which is a listener 
that spawns an instance of program C every time a new object (a) is introduced 
in the dataspace. This is modeled by extending the possible labels with the set 
{o, o I a € Name}, by adding the rules in Table 2 (we omit the symmetric 
rules of (17) — (19)) to the ones in Table 1, and by substituting the rule (2') 
for the rule (2). Negative premises are used in the new mles (see rules (17) 
and (19)), but the transition system specification is still stratifiable; thus, the 
operational semantics is well defined. 

The new labels a and a, represent the occurrence and the observation of the 
event “creation of a new object of kind a”, respectively. This event happens 
when an output operation is executed; for this reason we change the label 
associated to the prefix write{a) fi'om r to a (see the new rule (2')). Axiom 
(14) indicates that the notify {a, P) prefix produces a new instance of the term 
on(o, P). This term has the ability to spawn a new instance of P every time a 
new (a) is produced; this behaviour is described in axiom (15) where the label 
a is used to describe this kind of computation step. 

Rules (16) and (17) consider actions labelled with a indicating the interest 
in the incoming instances of (a). If one program able to perform this kind of 
action is composed in parallel with another one registered for the same event, 
then their local actions are combined in a global one (rule (16)); otherwise, the 
program performs its own action locally (mle (17)). Rules (18) and (19) deal 
with two different cases regarding the label a indicating the arrival of a new 
instance of (a): if there are terms waiting for the notification of this event are 
present in the environment, then they are woken-up (rule (18)); otherwise, the 
environment is left unchanged (rule (19)). 

In the following we use Lo[wrt3n] and Lu[wrt3n] to denote the language 
extended with the notify primitive interpreted under the ordered and unordered 
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semantics, respectively; on the other hand, Lo[wrtn] and Lu[wrtn] denote the 
two sublanguages without the read3 and take3 primitives. 

3.1. EXPRESSIVENESS OF NOTIFY 

Two of the authors have investigated the expressiveness of the notify prim- 
itive in two related papers. 

In [5] an interesting intermediary level of expressiveness is proved by show- 
ing that Lo [wrtn] permits to simulate RAMs, but only in a weak sense: this 
means that the representation we give of RAMs in our language have several 
possible behaviours among which one which corresponds to the one of the 
considered RAM. Moreover, the presented encoding has the property that all 
the other computations are ensured to be infinite; thus the encoding preserves 
termination. For this reason, the property P is not decidable. On the other 
hand, it is proved that P ^ is decidable by providing a divergence preserving 
encoding of the language in terms of Place/Transition nets extended with trans- 
fer arcs [8], a formalism in which the existence of an infinite computation is 
decidable. Moreover, it is also provided an encoding of the notify primitive in 
the language without event notification but with the test for absence operations. 
The idea is that when a process registers its interest in some particular event, 
it introduces a corresponding object into the shared repository. Every time a 
write operation is performed, a protocol composed of three phases must be 
executed: first it is necessary to count the number of registered listeners (by 
counting the corresponding objects in the shared repository), then to commu- 
nicate to each of them the occurrence of the event, and finally to wait for the 
total amount of acknowledgements. Moreover, this protocol must be executed 
in mutual exclusion. All the results proved in [5] for the language Lo [wrtn] 
hold also for Lu[wrtn]. 

In [4] the relation between the ordered and unordered interpretation is revis- 
ited in the presence of notify. The interesting result is that the calculus becomes 
Turing powerful also under the unordered interpretation, indeed we prove that 
RAMs can be encoded into Lu[wrt3n]; moreover, the notify primitive allows 
a faithful encoding of the ordered semantics on top of the unordered one. 

All these results are reported in the Figure 1. The three layers of expressive- 
ness are described recalling, for each of them, whether termination or diver- 
gence are decidable properties. We call the intermediary layer weakly Turing 
powerful for the fact that Turing formalisms can be simulated only in a weak 
sense. The existence of these layers ensures that it is not possible to encode 
one language inside a layer in another language inside a lower layer. Regarding 
the languages in the top layer, the arrow represents the existence of encodings 
from the language interpreted under the ordered semantics to the other two 
languages. 
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Tiiring Powerful 
P t and P 4. Undeddable 




Non Turing Powerful 

P t and P 4 Decidable 



Figure 1 Overview of the results about notify. 
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(24) 



(3') take(a, t)lP- Q — > take{a)t7P- Q 
(4') read(a, t)lP. Q — ^ read{a)t‘^P. Q 



take{a)t?P.Q P 
m+i'^P-Q-^vt^P-Q 
P^P' Q^Q' 
P\Q^P'\Q' 



(21) read{a)tlP-Q P 
(23) rjoW.Q-^Q 

p|g-4p'|Q 



Table 3 Operational semantics for timeouts (symmetric rule of (25) omitted). 



4. TIMEOUT 

In this section we consider the problem of modeling operations equipped 
with timeouts, which are used as extra parameters for the blocking operations 
read and take in order to indicate a maximum amount of time during which the 
presence of the requested object is investigated. If no instance is found before 
the end of this period, the operation fails and terminates. 

In order to model this kind of behaviour, we change the primitives read (a) 
and take{a) with the new read{a, t) and take{a, t) operations (where t defines 
the timeout period). These operations are no more used as prefixes of terms of 
the kind /i.P, but as guards of if-then-else forms rftP. Q. In this way, we can 
describe both the program P, chosen if the operation succeeds, and the program 
Q, activated if, on the contrary, the operation fails. 
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The way we represent time is inspired by JavaSpaces, where the current 
time is represented by an integer which is incremented each millisecond. If the 
execution of an operation with timeout period t is scheduled when the current 
time is c, the operation fails at the end of the interval with current time c + t. 

In our process calculus we do not use any value to represent the current 
time, but we only consider the passing of time, which is considered as divided 
into basic discrete intervals. Operationally, we model the instant in which an 
interval finishes, and the subsequent start, by means of a transition labelled with 

More precisely, we use P P' to state that the term P becomes P' due 
to the fact that the current interval has finished, and the subsequent just started. 
In this way, transitions related to the passing of time (labeled with and 
standard transitions representing coordination operations (with label different 
from cohexist in our labelled transition system. Morever, we do not put any 
restriction on the way these two kinds of transitions are related one each other. 
For example, we do not fix any bound to the number of standard transitions 
which can be performed between two y/ transitions. This choice reflects the 
fact that we do not make any assumption on the computation speed, thus neither 
on the number of coordination operations which may be performed during one 
basic time interval. 

The terms of our process calculus are of two different kinds: those sensible 
to the passing of time and those which are not. In the first case, the terms have 
outgoing transitions labelled with y/, while in the second they have not. 

As an example, the term (a) representing an object of kind a inside the datas- 
pace, has no outgoing transition labelled with y/ ; on the other hand, the program 
take {a)t^P-Q, representing the execution of a take operation with a remaining 

timeout period of t, has the transition take{a)t'?P- Q take{a)t-i^P- Q- 

Terms of the kind take{a)t^.P -Q cannot appear as initial programs of a 
configuration; they only arise as the result of the scheduling of a take oper- 
ation. The term take{a, t)'?P. Q is not sensible to the passing of time until 
the execution of the take operation is scheduled; this instant is represented 
by take{a, t)?P- Q take{a){^P. Q. The index t means that t complete 
intervals should pass before the operation fails; the failure is modeled by the 

transition take{a)o7P.Q <5 (in this way the failure happens after that ^ — 1 
transitions labelled with y/ are executed). 

We introduce the notation rjtlP.Q to denote either the term take{a)t'?P- Q 
or read{a)tTP- Q. The duration t is an integer number or a special symbol oo 
which denotes an infinite duration (we assume oo — 1 = oo). 

The new syntax is obtained by removing the read (a) and take{a) prefixes 
and by extending the possible guards of the if-then-else forms: 

r] ... | take{a,t) \ read{a,t) \ take{a)t \ read{a)t 
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The new semantics informally described above is modeled by introducing the 
new label y/ and the axioms and rules reported in Table 3 (the axioms (3') and 
(4') are substituted for (3) and (4), respectively). 

Axioms (3’) and (4’) model the starting of the timeout periods. Axioms (20) 
and (21) represent a successful execution of these operations, while axioms (22) 
and (23) represent the passing of time; the subscript t inrjt'?P- Q is decremented 
if it is not 0 (axiom (22)), otherwise the timeout period finishes and the second 
continuation is chosen (axiom (23)). The rules (24) and (25) describe how 
the structured term P| Q behaves according to the passing of time. If both the 
processes have an outgoing transition labeled with y/, they synchronize on the 
execution of this operation; on the other hand, one of the two processes can 
perform its own transition y/ locally, only if the other one is not sensible to the 
passing of time, i.e., it has no outgoing transitions labeled with y/. A negative 
premise is used in the rule (25), but the labelled transition system is still well 
defined. 

Observe that a timeout period may terminate even if the sought object is 
available. Thus, when an operation fails we cannot conclude anything about 
the presence or absence of the requested object. We have adopted this weak 
semantics as it seems the intended interpretation of JavaSpaces; see [15], where 
in Section 2.5 we read “A read request ... will wait until a matching entry is 
found ... up to the timeout period”. For example, in the configuration: 

(a) I read{a,t)?0-write{b) 

object {b) may be produced if (a) is not found before the end of the timeout t. 

4.1. SYNCHRONOUS V.S. ASYNCHRONOUS 
INTERPRETATION OF TIME PASSING 

We have modeled configurations in which the passing of time is global, i.e., 
it is the same for all the components. According to this approach, the time 
passes synchronously. This is ensured by the side condition o: ^ y' of the 
locality rule (11), according to which a processes cannot perform locally its 
own transitions y/. If we remove this side condition we obtain configurations 
in which the time passes asynchronously, as their components may or may 
not synchronize on the execution of their transitions labelled with y/. In the 
following we use P — P' to denote that a configuration P' can be reached 
from P via a sequence of reductions under the synchronous interpretation, while 
we use P — P" to denote that P" can be reached under the asynchronous 
one. 

The synchronous approach is used to model centralized systems with a global 
clock, while the asynchronous approach corresponds to distributed systems 
where the global clock is not available. Distributed and centralized systems 
usually present strongly different behaviours; however, we prove that for the 
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(2") write{a,t)?P.Q — ^ {a)t'\P with t' < t 
(2"') write{a,t)lP.Q ^ Q 

(1') {a)t 0 (26) (a)t+i ^ {a)t (27) (a)o -4 0 



Table 4 Operational semantics for leasing (symmetric rules omitted). 



calculus presented in this section this discrimination does not hold. On the 
other hand, we will see in the next section that the introduction of leasing in the 
calculus will permit to observe differences between the synchronous and the 
asynchronous interpretations. 

The equivalence between the two approaches is a consequence of the follow- 
ing theorem, stating that, given an initial configuration P, the configurations 
that can be reached from P are exactly the same under the synchronous and the 
asynchronous approaches. 

Theorem 1 Let P be a configuration not including terms of the kind rjt'lP- Q- 
We have that P — P' if and only if P — P'. 

The proof of the theorem is based on two observations: first, a computation 
under the synchronous approach is trivially valid also under the asynchronous 
one; second, the order of y/ transitions in a computation under the asynchronous 
approach can be changed in order to obtain another valid computation leading 
to the same configuration such that the new computation can be mimicked under 
the synchronous approach. Intuitively, this can be done because there is no way 
to observe the instant in which a timeout period starts, instant which is modeled 
by transitions labelled with r (see mles (3’) and (4’)) 

5. LEASING 

Leasing represents an emerging style of programming for distributed systems 
and applications. According to this style, a service offered by one object to 
another one is based on a notion of “granting the service for a certain period of 
time”. In this way, objects which ask for services declare also the corresponding 
period of interest in that service. The server decides whether to grant the service 
for the complete period or for a shorter one. These are usually called leased 
services. 

In JavaSpaces the notion of leasing is introduced in relation to the write and 
notify operations. In [6] we have modeled leased versions of these two opera- 
tors by adding an extra parameter which represents the duration of the interval 
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for which the emitted datum should be maintained inside the data repository 
(for write) or the amount of time after which the listener for the event should 
be removed (for notify). Moreover, two further primitives renew and cancel 
are introduced in order to extend the duration or to terminate the leasing period 
of a particular previously defined leased service. 

For simplicity, in this paper we only present a modeling of leasing for the 
write operation; moreover, we omit the renew and cancel operations (see [6] 
for the complete treatment). 

The syntax of the calculus extended with leasing uses the write operation 
no more as a prefix, but as a guard of if-then-else form: 

rj ::= ... | write{a,t) 

In order to associate to the leased objects the indication of the remaining lifetime 
t, we use a subscript notation t. Namely, we represent objects with {a)t to 
indicate that the represented object will be removed after t basic time intervals 
due to the expiration of the leasing period. 

The operational semantics is redefined by adding the new axioms in Table 4 
where (!') is substituted for (1) while (2") and (2'") are substituted for (2'). 

Axiom (2") models a successful execution of an output operation; the side 
condition represents the fact that the new object may be leased with a lifetime 
shorter than the requested one. Axiom (2'") indicates that the output operation 
may also fail; in this case the second possible continuation is activated. The 
other axioms describe the semantics for the shared objects (o)t which may be 
read/consumed (axiom (!')), may reduce their remaining lifetime as effect of 
the termination of a basic time interval (axiom (26)), or may be removed as 
effect of lease expiration (axiom (27)). 

5.1. SYNCHRONOUS V.S. ASYNCHRONOUS 
INTERPRETATION OF TIME PASSING 

Also in the language extended with leasing, we could think to adopt either 
the synchronous or asynchronous interpretations of time passing described in 
the previous section. It is interesting to observe that the introduction of leased 
resources permits us to distinguish between them, formally, the Theorem 4. 1 
does not hold any more. As a counter example consider the following program: 

write{a, t).read{b, t + 1)?0_ take{a) 

After the execution of the write operation the following term is obtained: 
{a)t\read{b, t + 1)?0_ take{a) 

The right hand process requires the presence of object (6) in order to continue 
its execution. As this object will never be produced, its behaviour consists of 
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waiting for a t + 1 long period, and then becoming process take (a). The object 
on the left has a lifetime shorter than t + 1. According to the synchronous 
interpretation, {a)t disappears before take (a) can be performed, while this is 
not true under the asynchronous one. Thus, the take {a) operation may succeed 
only under the asynchronous approach. 

The above example shows that it is no more true that the configurations 
reachable from an initial configuration are exactly the same under the two in- 
terpretations. The example uses a read operation with timeout. An even more 
discriminating result between the two interpretations is proved in [7] for a 
calculus without event notification and timeouts; in other words, a calculus cor- 
responding to the kernel language defined in Table 1 where the write operation 
is substituted by the one defined in Table 4. 

For this simple language we have proved a gap of expressiveness between the 
two interpretations for the passing of time by considering the ability to encode 
RAMs under synchronous and asynchronous time. 

Concerning asynchronous time, we have presented a RAM encoding which 
preserves termination, and we show the impossibility to define encodings which 
preserves divergence. This result is achieved by proving that P 'I is a. decidable 
property in this language. Even more interesting is the analysis of synchronous 
time; we show two possible encodings, the first which preserves termination 
and the second which preserves divergence, and we prove the impossibility to 
define encodings which preserves both termination and divergence. In order 
to achieve this result we first observe that given an encoding which preserves 
both termination and divergence, we have that for any RAM, the corresponding 
encoding is uniform with respect to termination or divergence (i.e., its compu- 
tations are either all finite or all infinite). After, we prove that P f is decidable 
for uniform processes. 

The above results are summarized in the following table where we report also 
the results proved regarding the relation between the ordered and unordered 
interpretations for the output operation proved in [2] and recalled in the In- 
troduction. The table reports the properties that the encoding of RAMs may 
preserve: 





Termination 


Divergence 


Termination & Divergence 


Ordered Output 


YES 


YES 


YES 


Leasing Sync. Time 


YES 


YES 


NO 


Leasing Async. Time 


YES 


NO 


NO 


Unordered Output 


NO 


NO 


NO 



6. CONCLUSION 

We have proposed a formal semantics for primitives typically adopted by 
Linda-like coordination middlewares, with a particular emphasis on the inno- 
vations introduced in JavaSpaces specifications. 
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In particular we have focused on alternative interpretations of two kinds: 
ordered v.s. unordered interpretation for the output operation, and synchronous 
v.s. asynchronous interpretation for the passing of time. The most interesting 
results are: 

1 The event notification mechanism introduces an intermediary level of ex- 
pressiveness: the calculus with output, input, read, and notify is Turing 
powerful in the weak sense xmder both the ordered and unordered inter- 
pretations; the calculus extended with event notification becomes Turing 
powerful also under the unordered approach. 

2 The synchronous and asynchronous interpretations for the passing of 
time are equivalent in the presence of time-outs only, while they are 
discriminated by an expressiveness gap in the presence of distributed 
leasing. 

Moreover, further observations follows from the results reported in the table 
of Section 5.1. The critical point is that under leasing, when an output operation 
requires to place in the space a new object with a certain duration, “if the 
requested time is longer than the space is willing to grant, you will get a lease 
with reduced time”. This implies that the classic, persistent, (ordered) output 
operation is no longer available. This suggests why the expressive power should 
decrease, and indeed we formally proved that this is the case. Moreover, if 
time is not global, then we loose also the possibility to observe the instant in 
which a lease expires. And this explains intuitively the second expressive gap. 
Finally, we have that a language where there is control over the time a datum 
is introduced in the dataspace, but little control on the time of permanence, is 
more expressive than a language where there is no control over the time a datum 
is introduced (unordered output), even if then the datum is persistent. 

The results we have proved on our JavaSpaces based process calculi might 
lead to reconsider the choice of the coordination operators and their semantics. 
One idea, for example, could be to move fi’om the ordered semantics to the 
unordered one; indeed, we have proved that the presence of notify allows us 
to simulate the ordered semantics (and this simulation can be exploited only in 
those particular cases in which the order is strictly necessary). In other words, 
we are convinced that these results can be considered not only a first step in 
the direction of a better and formal understanding of the coordination model 
advocated by JavaSpaces, but they also represents insights useful in the design 
of new JavaSpaces-like languages. 
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Abstract This paper introduces an abstract model for distributed and mobile com- 
putation, based on a notion of domains. The model is shown expressive 
enough to simulate faithfully several recent distributed process calculi 
such as the Mobile Ambient calculus and the DJoin calculus. This in 
turn hints at the relevance of the model as a basis for the development 
of a primitive formal model for distributed and mobile programming. 

Keywords: Distributed and mobile computation, formal model, distributed process 
calculi, TT-calculus, mobile ambients, DJoin calculus. 

1. INTRODUCTION 

Despite advances, during the last decade, on mobile process calculi, 
a primitive model for distributed and mobile programming remains elu- 
sive. For this reason, several recent works, e.g. [1, 4, 6, 8, 22], have 
introduced distributed process calculi, which aim to capture features 
such as the distribution of resources on different locations, process mo- 
bility, the impact of failures and security on the behavior of a system, 
etc. 

These distributed process calculi shaxe several characteristics : 

■ they are based on some asynchronous variant of the 7r-calculus [13]; 
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■ they introduce a notion of locality to capture different features of 
distributed programming. 

Despite their similarities, it is difficult to directly compare these cal- 
culi, for the notions of localities they introduce obey very different rules, 
reflecting the different kinds of phenomena they are intended to cap- 
ture (mobility across nodes, failure models, administrative domains, etc). 
Apart from [7], which defines (and proves correct) a translation of the 
Ambient calculus [4] into the join calculus [6], we know of no systematic 
attempt to relate these different models of distributed computation. 

This paper intends to All this void : 

1 by defining a more abstract and more general model of distributed, 
object-based computation; 

2 by showing how these process calculi can be directly and faithfully 
simulated using instances of our model, hinting at the relevance of 
our model as a general model of distributed (and mobile) compu- 
tation. 

The paper is organized as follows : 

■ Section 2 motivates the introduction of the notion of domain as a 
central feature of a model for distributed and mobile computation. 

■ Section 3 introduces our model. 

■ Section 4 presents faithful simulations of two distributed process 
calculi in our model. 

■ Section 5 identifies perspectives for further work. 

2. DOMAINS 

In this section we introduce the notion of domain^ and we derive a 
number of requirements for a model of distributed computation centered 
around this notion. 

2.1. THE NOTION OF DOMAIN 

Large distributed systems such as the World Wide Web or wide area 
telecommunications networks share several characteristics: 

■ asynchrony: processing and communication in these systems occur 
at different speeds, without reliance on a common global clock. 

■ partial failures: parts of a large distributed system may fail inde- 
pendently, according to different failure modes. 
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■ system partitions: a large distributed system comprises several, 
possibly overlapping sub-systems, organized around different con- 
tingencies such as location, security, failure modes, administration 
and management. 

This suggests that, from a modeling point of view, a distributed sys- 
tem should primarily be understood as a partitioned system. Com- 
ponents of a distributed system can be grouped in different, possibly 
overlapping sets, generally under the control of a single object or entity. 
Adopting the terminology from [9], we shall call domains such sets of 
components. 

Domains come in many varieties, for instance : 

■ resource domains, encompassing hardware and software resources 
under the control of a single resource manager (e.g. information 
processing nodes in a computer network); 

■ language domains, delineating address spaces dedicated to the exe- 
cution of programs written in a single programming language (e.g. 
capsules [10] or operating system processes); 

■ failure domains, encompassing entities that may fail together, ac- 
cording to certain failure modes (e.g. fail silent machines); 

■ administrative domains, encompassing computing resources under 
the control and management of a single authority (e.g. network 
management domains); 

■ security domains, corresponding to sets of nodes controlled by se- 
curity policies and firewalls; 

■ naming domains, corresponding to sets of entities designated ac- 
cording to a given naming policy; 

■ locations, encompctssing entities located at a given address in a 
computer network; 

■ technology domains, encompassing systems that are built with, 
or use a common hardware or software technology (e.g. intercon- 
nected machines that use a common set of communication proto- 
cols). 

Notions of ambients in the Ambient calculus [4], of seals in the Seal 
calculus [22], of localities in the Join calculus [6], in the 7Ti/-calculus 
[1], and in the Dyr-calculus [8], seem to correspond to variants of this 
general notion of domain. In these calculi, domains are used to m ake 
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explicit the spatial structure of computations (as flat or tree-shaped sets 
of domains). However they differ in the (implicit) particular behavior 
they attach to their respective notion of domains. 

These calculi adopt a homogeneous view of domains, each domain be- 
ing capable of a single behavior (e.g. with respect to failure or process 
migration). In a large distributed system, however, domains of various 
kinds coexist. It is thus important, in a model for distributed computa- 
tion, to take into account different kinds of domains, with possibly very 
different behaviors. This leads us to our first requirement on a model 
for distributed computation: 

Requirement 1 A model of distributed computation should include^ as 
a primitive conceptj a notion of domain^ understood as a means to spa- 
tially partition a distributed computation^ and should allow the definition 
of arbitrary domain behaviors. 

2.2. BEHAVIOR OF DOMAINS 

^Prom the examples given above, it appears that a domain can be 
characterized by two elements : 

■ a set of objects belonging to the domain, which we shall call the 
content of the domain; 

■ a controlling object, attached to the domain, which we shall call 
the container of the domain. 

Let us consider what general requirements apply to these elements. 
First, the container of a domain can play the role of a filter with respect 
to messages which are sent to the domain’s content. This type of behav- 
ior is manifest, for instance, in firewalls (containers for security domains), 
or in so-called component containers such as e.g. in EJB (Enterprise Java 
Beans) [20] or CORBA Components [17]. Modeling network nodes with 
their protocol machinery, at various levels of abstractions, also requires 
the introduction of domains and of their associated containers, capa- 
ble of intercepting and processing incoming and outgoing protocol data 
units. We record this as 

Requirement 2 A domain container should be allowed to intercept and 
process messages which are going to, or coming from, the domain con- 
tent, possibly changing its own state in the process. 

Another requirement is for domain containers to evolve exactly as a 
standard object, by receiving and sending messages to their environ- 
ment. System management applications, for instance, typically require 
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access to domain containers (e.g. for querying the state of a given ma- 
chine, for shutting it down, for activating it, etc). These applications 
further illustrate the fact that state changes of a domain container may 
cause correlative changes in the domain content. For instance, shut- 
ting down a given machine, understood as both a resource domain and 
a failure domain, will cause the different computations it supports to 
be terminated (and, perhaps, moved to different storage containers in a 
“passive” state). We record this as 

Requirement 3 A domain container should be allowed to send and re- 
ceive messages, thereby changing its state, and possibly causing state 
changes in the domain content as well, 

A final requirement pertains to the creation of new domains and to 
the migration of contents between domains. Dynamic reconfiguration in 
an open distributed system implies the ability to introduce new objects 
and new subsystems, e.g. to increase the capacity of the system under a 
changing load, or to update parts of the system with new (hardware or 
software) technology. Modeling mobile systems, i.e. systems with phys- 
ically mobile subsystems (portable PCs, PDAs, mobile phones, etc) or 
mobile software objects (e.g. mobile agents), implies the ability to move 
objects between different domains, corresponding to different spatial lo- 
cations (e.g. from one radio cell to another, from one host to another). 
This translates into the following requirement 

Requirement 4 It should be possible to dynamically create new do- 
mains, and to move all, or part of a domain content from one domain 
to another. 

3. MODEL 

We introduce in this section an abstract computational model that 
takes into account the various requirements identified in section 2 above. 

The model is abstract in that it does not provide an effective means to 
describe the individual behavior of domains. Instead, the model postu- 
lates, for each domain, a behavior description which is expressed in terms 
of sets of possible transitions (given by operator B below). However, we 
shall see in section 4 below that this model can ea-sily be instantiated to 
yield concrete (sub-)calculi. We shall discuss in section 5 perspectives 
for the definition of a concrete process calculus based on a notion of 
domain. 

Our model is both object-based and domain-based in that: 

■ a distributed system is described, using our model, as a collection 
of concurrent, interacting domains (a configuration); 
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■ each domain is, in turn, constituted by the composition of an ob- 
ject, the domain container^ with a configuration, the domain con- 
tent 

The operational semantics of our model is defined in the Chemical 
Abstract Machine style [2], using a structural equivalence, =, and a 
reduction relation, — )►. 

3.1. SORTS AND OPERATORS 

We postulate the existence of different sorts and operators. We adopt 
a postfix notation for operators. Sorts of our model are as follows: 

■ N denotes the set of names in our model. Intuitively, each object 
in the model exhibits diflFerent interfaces (as per the ODP Ref- 
erence Model [9, 10]) which are identified by unique names. An 
interface constitutes a communication port. We use u, -u, and their 
decorated variants to refer to names. 

■ O denotes the set of objects in our model. We use a;, w and their 
decorated variants to refer to objects. 

■ M denotes the set of messages in our model. We use m and its 
decorated variants to refer to messages, and and its decorated 
variants to refer to finite (possibly empty) bags of messages.^ 

Messages are units of interaction between an object and its environment. In 
this paper, we only consider asynchronous message exchange as a means of 
communication. An immediate extension of the model would consist in the 
introduction of so-called bindings^ e.g. along the lines of [15]. 

■ S denotes the set of configurations. We use C, jD, jB, F and their 
decorated variants to refer to configurations. We assume that S has 
two distinguished elements, 0 and ±, which denote, respectively, an 
empty configuration and an invalid configuration. A configuration 
corresponds to a parallel composition of domains and messages. 
With operators || and [ ] below, an abstract syntax for configura- 
tions is given by the following grammar : 

C 0 I ± 1 m I u[C] \ C\\C (1) 

Operators in our model are (we omit injection operators from 0 into 
S, and from M into S) : 



^We also use to refer to a configuration mi || ... |1 mp of messages This is legitimate, 
thanks to the associative and commutative properties of the parallel operator, ||. 
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■ ||:SxS-^S 

Operator || is the parallel composition operator in our model. 

■ []:OxS-^S 

Operator [ ] is a composition operator that constructs a domain 
u[C] by associating an object a; and a configuration (7. a; is the 
container of the domain o;[(7], while C is the content of domain 

■ : M N 

m.tgt denotes the destination of message m. 

■ arg : M (N U S)* 

m.arg denotes arguments (in finite number) of message m. An 
argument of a message can be either a name, or a configuration. 
We note u{l) a, message with target u and with arguments given 
by vector 1. 

■ Li : 0 -)• p/(N) 2 

uj.Li denotes the set of names born by object u). 

■ L : 0 — (S — > py(N)). 

uj.L{C) denotes the set of names born by domain a;[C], and which 
are visible by its environment. 

Operator L is extended into an operator L : S p/(N) on config- 
urations through the following inductive definition : 

- 0.L = 0 

- m.L = [j{C.L • C G m.arg} 

- u)[C].L = u.L{C) 

- {Cl II C2).L = Ci.L\JC2.L 

A domain cj[C'] exhibits a number of interfaces which are visible by its envi- 
ronments as a set of names (given by u.L(C)). These names may differ from 
the names born by configuration (7, e.g. we can have uj.L{C) D C.L = 0 
: a domain’s container controls the visibility of the domain’s content from 
other objects in the environment of the domain. In general, we will also have 
o;.L2[0] ^ u.L\. This means that interfaces of an object uj may in general 



^We use p/(A) to denote the set of finite subsets of a set A, Bagf{A) to denote the set of 
finite multisets built with elements from set A, and p(A) to denote the set of subsets of set 
A. 
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be split between internal interfaces, i.e. interfaces which are only visible from 
the content of a domain o;[C], and external interfaces, i.e. interfaces which are 
visible from the environment of a domain u[C]. 



m : 0 (S p/(N)) 

uj.K (C) denotes the set of names known by domain u[C]. Operator 
K is extended into an operator K : S pf{N) on configurations 
through the following inductive definition: 

- (b.K = fb 

- m,K = \J{C.K • C G m.arg} U \J{m,arg • m.arg G N} 

- lj[C],K = lj.K{C) 

- (Cl II C2).K = Ci.KUC2.K 

■ B : 0 ^ {S p{0 X Bagy(M) x S)) 

uj.B denotes the behavior of object u). Given a configuration C, 
the behavior of domain cu[C] is defined by a set of possible transi- 
tions, i.e. of triplets of the form (a;, D). In a possible transition 

(a;, is a multiset of messages targeted at names born by 

a;[C], and D denotes a new configuration, created at the end of 
the transition. The behavior of an object must obey certain con- 
sistency conditions which are given in Section 3.3. We use t and 
its decorated variants to denote possible transitions. 

3.2. STRUCTURAL EQUIVALENCE 

The structural equivalence between configurations is defined induc- 
tively as being the smallest relation satisfying the following rules: 



c = c 


(2) 


C = D 
D = C 


(3) 


Cx = C2, C 2 = C-3 
Ci=C 3 


(4) 


Cx=C2 

Cx\\D = C2 II D 


(5) 


C = D 
oj[C] = w[D] 


(6) 



Vi G {1, . . . ,p} • li = ki if li eN li = ki ifk eS 
u{k,...,lp) =u{ki,...,kp) 

C\\D = D\\C 



(7) 

( 8 ) 
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{Cl II (72) II (73 = Cl II (C 2 II C 3 ) 


(9) 


C II 0 = C 


(10) 


C||X = X- 


(11) 



Relation = is an equivalence relation: rules (2), (3), (4). It is also a 
congruence on configurations: rules (5), (6), (7). The parallel operator 
is associative, commutative, has 0 as a neutral element, and X as an 
absorbing element: rules (8), (9), (10), (11). 

The value of proposition (7 = X is given by the following inductive 
definition: 

■ (0 = X) = False 

■ (m = X) = \/cem.arg C = ± V Hcem.arg ® 

■ {u}[C] = ±) = (lo.Li n C.X 7^ 0 V (7 = X) 

■ {Cl II C2 = X) = {Ci.L n C2.L 7^ 0 V ( 7 i = X V C2 = X) 

Configuration ± is a technical artifact which is used to enforce the unicity of (visible) 
names in a configuration. The unicity of names in a given configuration C can be 
simply stated as : C ^ _L. Note that the definition above disallows a recursive building 
of domains, e.g. in domain cj[C'], object u cannot appear as a domain container in 
C. 



3.3. OBJECT BEHAVIOR 

Possible transitions associated with the behavior of an object (as given 
by operator B) are subject to certain consistency conditions. Possible 
transitions t = (a;, associated with the behavior of an object uj 
can take two different forms, according to the structure of the resulting 
configuration D: 

■ Standard domain evolution: 



D = J[E] II F (12) 

where F is a configuration and (j.Li C lo' .L\. 

Intuitively, object uj’ corresponds to the “new state” of object cj after the 
transition. Interfax:es of an object persist during a transition, which is captured 
by the condition u.L\ C u' .L\. 

■ Domain “passivation” : 



D = m{u;'[E]) || F 



(13) 
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where F is a configuration, m{(jj'[E]) is a message that has u'[E] 
as an argument, and uj.L\ C u'.Li. 

Intuitively, in this sort of transition, a domain “passivates” itself into a message, 
targeting a known interface. This feature is crucial for the expressive power of 
our model. 

We shall denote by Hi{t,C) the fact that these two possibilities are 
allowed: 

D),C) =def 3oj',E,F • uj.Li Q u)' ,Li 

A (D = u'[E] II F V £> = A^'[E]] || F) 

If t is a possible transition of the behavior of object w with content 
C, i.e. t € (jj.B{C), then t must be of the form {u, K, D) and must verify 
condition H{t,C), defined by: 

H{{uj,'R,D),C) ^def D.K C u}[C].K\J\<.K\JD.L (14) 

A '^.tgt C u[C\.L (15) 

A (16) 

Condition (14) stipulates that names known after a transition must have been 
known by the domain prior to the transition, must appear as arguments of incom- 
ing messages in or must be born by new interfaces created during the transition. 
Condition (15) stipulates that the target of incoming messages in a transition are 
restricted to names born by the domain. Condition (16) stipulates that the configu- 
ration resulting from the transition must respect the unicity constraint on names. 

To ensure compatibility with the structural equivalence defined in the 
preceding section, condition must be verified. Condition 

H 2 [t^ C', K', F') is defined thus, with t = (a;, D): 

H2{t, C', F') =def t e u.B{C) A C = C^ A ^ = W A D = D' 

euj.B{C') 

Intuitively, ^ D') states that the behavior of an object for a given con- 

figuration C remains the same for any equivalent configuration (7'. 

The consistency condition on object behavior thus takes the form: 

Cons(o;) =def e S e u;.B{C) • H{t,C) A Hi{t,C) 

3.4. REDUCTION RELATION 

In our model, a system corresponds to a transition system whose set 
of states is given by S, and whose transitions are given by the reduction 




Object-based model for distributed computation 33 

relation inductively defined as the smallest relation derived using the 
following rules: 

■ Domain evolution: 

euj.B{C) Cons(a;) (17) 

u}[C\ p ^ P 



This rule stipulates that a domain u)[C] evolves in accordance with the (con- 
sistently) defined behavior for object w, given configuration C. 

■ Paxallel evolution: 



C\\Dj^± C ^ C C'WD^L 
C\\D ^ C'\\D 



(18) 



This rule stipulates that configurations in parallel can evolve independently, 
provided the unicity of n^tmes is preserved. 

■ Evolution of equivalent configurations: 



C = D D D' D' = C 
C C 



(19) 



This rule stipulates that evolutions of equivalent configurations are identical. 

3-5. DISCUSSION 

The model we have just presented, which we shall call the k model, 
meets in large part the requirements set out in section 2 : 

1 The notion of domain is primitive in the k model and allows for 
arbitrary domain behaviors (as manifested by operator B in the 
definition of an object behavior). 

2 In the k model, a domain container can intercept and process in- 
coming and outgoing messages ultimately targeted at the domain 
content. This feature is illustrated in the simulations presented in 
section 4, e.g. in rules (28) and (30). 

3 In the k model, a domain container constitutes a a bona-fide ob- 
ject, with its own behavior and the capacity to receive and emit 
messages. Simulations in section 4 rely heavily on the modeling of 
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a domain container (ambient or DJoin locality) as an object (see 
in particular rules (28) to (35), and rules (50) to (55)). 

4 Domain creation and domain passivation are integral features of 
the K model, as defined in section 3.3. Again, these features are 
crucial for the simulations in section 4, as illustrated e.g. in rules 
(28), to (31). 

Further evidence in meeting the requirements laid out in Section 2 
can be found in the report [18], as well as a more detailed analysis of 
the requirements. In addition, it is shown that the n model constitutes 
a conservative extension of the RM-ODP computational model [9], and 
that the k model captures the main constructions involved in concurrent 
refiective systems such as ABCL/R [23] and Coda [12]. 

4. SIMULATIONS 

We present in this section faithful simulations, in the n model, of the 
Mobile Ambients calculus [4] and of the DJoin calculus [6, 7]. These 
simulations provide a direct characterization of the kinds of domains in- 
troduced by these two formalisms (ambients and localities, respectively). 
More precisely, they show that, using our model, it is possible to fully 
characterize notions of domains introduced in these calculi as objects 
(domain containers) endowed with specific behaviors. 

Throughout the section, we use a simplified version of our model, 
where u)[C].L = uj.Li U C.L^ and where uj[C].K = U C,K. 

We describe object behaviors using an operational style, where pos- 
sible transitions are given in the form of inference rules. Intuitively, a 
rule 

Premiss 

Configi -)► Config 2 

describes a possible transition of the object present in configuration 
Configi^ provided the condition captured by Premiss is met. 

4.1. SIMULATION OF MOBILE AMBIENTS 

For simplicity, we consider the simple ambient calculus (i.e. without 
communication), as defined in [4]. The simulation of mobile ambients in 
our model uses the following elements: 

■ Every ambient of name n is simulated with an object AJJ, where 
u G N. 
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■ We denote by Name the set of names used in the ambient calculus. 
We use n, m, and their decorated variants to denote elements of 
Name. 

■ To each name n of the ambient calculus is associated a gateway 
object which is required in order to simulate the presence of 
multiple ambients with the same name n. 

■ A simulation of an ambient calculus process makes use of a global 
container u)q{U^ V)^ which is parameterized with two sets of names 
U C Name and F C N. This object is in charge of managing name 
creation. 

■ We 2 tssume given an injection -0, from Name into N. 

■ We use the following distinguished names from N : in, out, open, 

act, include, extrude. 

Let P be an ambient calculus process. A simulation of P in the k 
model is given by function Tq, which is defined by: 

To(P) = MU, V)[T{P) Wneu t^nD] (20) 



where U = {n ■ n E FV{P)}, et V = xp{U). 

Function T is defined inductively by; 

■ T(O) = 0 

■ T{P\Q)=T{P)\\T{Q) 
m T{\P) = bang[T(P)] 

■ T(n[P]) = amb(n,P) 

■ T{inn.P) = V>(n)(in,T(P)> 

■ T{outn.P) = (out, T(P)) 

■ T{openn.P) = V’(n) (open, T(P)) 

■ T{un.P) = new(n, P) 

Additional objects used by the simulation are defined below. 

The global containers u)q{U,V) are defined hy uJo{U,V).L = ih and the 
following behavior: 

m^U U' = UU{m} V = VO {rp{m)} 
wo(C/,F)[new(n,P)] ^tuo(C/', II r(P{w/n})] 

w 0 V U V’(Name) V' = VO {«} 
wo(C/,F)[amb(n,P)] u;o(17, F')[A“[T(P)] || V-CnXact, «)] 

uEV 

u)o(U,V)[i{gate,C) || D] ^ uJo(U,V)[u(gate,C) || D] 



( 23 ) 




36 



‘^o(C/,y)[t{gate,C> II D] u;oiU,V)[C || D] 

C -» C' 

cjo{U,V)[C] -> uo{U,V)[C] 

ujo{U,V)[C] -> wo{U' ,V')[C] 
MU,V)[C II D] uJo{U',V')[C II D] 

ojo{U,V)[C] uojU' ,V')[C] 

o,o{U,V)[A^[C]] -> m{U',V')[Al[C']] 



(24) 

(25) 

(26) 
(27) 



Objects are defined by A^.L = {u}, and the following behavior: 
Al[C II «(in, D)] ^ ?;(include, Al[C || D]> (28) 



Al[C] II u(include, D) ^ Al[C || D] (29) 

An[C II v(out, £))] -> t;(extrude, AJJIC || D]) (30) 

^“[C II u(extrude,D>] ^ Al[C] || D (31) 

Al[C]\\u{oper^,D)-^eu[i\\C\\D (32) 

(33) 

Al{C] ^ Al[C] 

Al[C II ZUm[D]] ^ A^[C7] II ZUra[D] (34) 

yi::[C]||w(gate,Z?>^^;;[C||D] (35) 



Object €u is just defined by eu-L = {u}. Object new(n, P) is just 
defined by new(n, P).L = 0. 

Object bang(P) is defined by bang(P).L = 0 and the following behav- 
ior: 

bang[T(P)] ^ bang[T(P)] || T(P) (36) 



The gateway objects, Wn are defined by vjn-L = '0(n) and the follow- 
ing behavior: 

^n[C] 4<(gate, tUn[C]) (37) 

^n[C] II V^(n)(act,w) -> ‘^n[C II V^(n)(act,ii)] (38) 

I = h, . . . ,lp Zi e {include, extrude, open} 

Wn[C II rp(n){act,u)] || ip{n)(l) vJn[C || V>(n)(act, u>] || u{l) 



(39) 
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Let ^[-] be a context from k, and P an ambient calculus process. 
Context ^[-] and process P are said to be compatible if ^[-j takes the form 
^[•] = u}o{U,V)[\\neu ^^n[^n] || ‘ lUeVi with if){U) C F, C F, 
is a set of messages such that tp{n){act,u), u GV, and if P is such that 
FV{P) C U. 

One can then show the following: 

Proposition 1 Let P and Q be two ambient calculus processes, such 
that P —^ambient Q- Then, for all k contexts ^[-], such that ^[-] and P are 
compatible, there is a n context ^f-1, such that and Q are compatible, 

and^TiP)] 

Proof By induction on the form of derivation contexts in the ambient 
calculus. ^ 

Let us just illustrate a proof step and the way the simulation works. 
We consider the following rule from the ambient calculus: 

n[inm.P \ Q\ \ m[i?] m[R \ n[P \ Q]] (40) 

Let A = n[inm.P \ Q] \ m[R] and B = m[R \ n[P \ Q]]. We have the 
following derivations, where V — V U {u, u} : 

= wo(J7, II tVm[Nm] || amb(n, mm.F || Q) || amb(Tn,F)] 

->■* Wo(C^, V')[ro„[N„] II || 

A^[T{inm.p \ Q)] || ^(n)(act,u) || Al,[T{R)] || V’(m)(act,t;)] 

= Wo([/,t^')[l^n[«n] II || 

^“[V>(m)(in> II T{P) II T(Q)] || V-(n){act,«) || A;^[T(F)] || V.(m)<act, v)] 

->* wo(C/,t^')[u7„[K„ II V’(n)(act,M)j || || rp(m){act,v)] || 

V>(m)(include, A“[T(P) || T{Q)]} || ^;^[T(F)]] 

uo{U,V')[n7n[‘i^n || ip{n)(act,u)] || || ip{m){act,v)] II 

t;(include, A“[T(P) || T(Q)]) || ^j;.[T(P)]] 

ojo{U,V')[zon[^n || V’(w)(act, u)] || || i){m){act,v)] II 

AUT(R) II Al[T{P) II T{Q)]]] 

= ^'[T(B)] 

4.2. SIMULATION OF THE 
DJOIN-CALCULUS 

We consider the D Join-calculus as defined in [6, 7]. Simulating this 
calculus in our k model involves several elements: 

■ Each locality a|] from the DJoin-calculus, for a an elementary local- 
ity, is simulated by a domain .AaO- A higher- level locality oi . . . Op[] 
is simulated by a set of embedded domains Aai[. . . [AapO] • • •]• 

■ To each receiver x of the Djoin-calculus is associated a gateway 
object vOx- Simulating a definition in the D Join-calculus involves 
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the creation of gateways for all the names which are defined at the 
first level in a Djoin definition D. 

■ We assume given an injection (f) from the set Name of names of 
the D Join-calculus, into N, the set of names of the k model, (j) 
associates to each name of the DJoin the name of the gateway or 
of the domain that corresponds to this name. 

■ The simulation of a DJoin calculus process makes use of a global 
container ujq{U^ F), which is parameterized by two sets U C Name 
and F C N. 

■ We use x^y^z to denote a channel in the DJoin calculus, a, /? to 
denote a higher level locality in the D Join, a, h to denote base 
level locality in the D Join, and n, m to denote arbitrary localities 
(concatenations of base level localities a, 6). We use u^v to denote 
names in /^, and I to denote an arbitrary message argument in k. 

■ We use the following distinguished names from N : go, act, hab. 

Let P be a DJoin-calculus process. We define a simulation of P in k 
with function Tq, defined as: 

To{P)=MU,V)[T{P)] (41) 



where {/ = {n • n G FV{P)} and V = {</>(«) • n G U}. 

Function T is defined inductively by: 

■ T{x{y)) = <t>{x){4>{y)) 

m T{Pi I P 2 ) = T(Pi) II T{P2) 

■ T(0) = 0 

■ T(defDinP) = def(L>, P) 
m T(J>P) = prep(J,P) 

■ T(L>i AP>2 )=T(L>i) ||T(P2) 

■ T{m[D : P]) = loc(7n, D, P) 
m T(go(a);P) = go(a,P) 

Objects which are used by the simulation are defined below. 

Global containers ojq{U,V) are defined by u}o{U,V).L = 0, and the 
following behavior. In what follows we note 

A{D) =||agpO Aa[ ||6gp^ ■46[. ■ • [ ||(^gpJV(a) ]•••]] 

with = {ao • aoai . . .aq G M}, = {a^ • aoai . . . ak . . . aq e M, ao . . . ak-i = 

u }, and N{a) = max{/c • P!^ ^ u — aa\ . . . aq} . 

^ y y e dv{D)] U' = ran(//) V' = V \J 0(ran(/x)) / 

uJoiU, y)[def(D, P)] ^ a;o(C/', y')[defn(P{y/x}(,,,)^^, P{y/x}(,,,)^^) ] ^ ^ 




Object-based model for distributed computation 39 



-P — > Pj) f\m€M 

c^o(P,F)[defn(P,F)] ^ ujo{U' ,V')[T{D) || T(P) ||.ex tu.Q || A{D) ] 



(43) 



m — flo^i • • • Up Tt — cii . . . Up 

ujo{U, T/)[loc(m, D, P)] ■«-»• ojoiU, V)[?i(ao){hab, loc(n, D, P)> ] 
wo(C/, V^)[loc(a,£»,P)] ^ wo(r/, V)[^(a)(hab,T(D) || T{P)} ] 

p= {x >-> u ■ X S dv{J), u U (^(Name)} V' = F U ran{p) 
(^o{U,V)[prep{J, P)] u)o{U,V')[react(J, P, p) lUedt^U) ^(a:)(act,p(x))]> ] 

c c 

wo(t/,r)[C] uo{U,V)[C] 

a>o(I/,V)[C7] -> ujo{U'X)[C] 
oJo{U,V)[C II D] uJo{U' ,V')[C II D] 

ujo{U,V)[C] ^ uJo{U',V')[C] 
i^a{U,V)[Aa[C]] ^ LJo{U' ,V')[Aa[C']] 



(44) 

(45) 

(46) 

(47) 

(48) 

(49) 



An object Aa is defined by A^.L = {<^(a)} and by the following be- 
havior: 



C C 
Aa[C] Aa[C] 



(50) 



Aa[C] II fli.(a){hab, D) o A„[C || D] (51) 



Vj G C.L/ 

Aa[C] II u(t) Aa[C II U{ 1 )] 
Aa[C II U(Z)] Aa[C] II U{I) 



Aa[C II go(a,P)] -> <^(a)(go, Aa[C7 || T(P)]) 



(52) 

(53) 

(54) 



Aa{C] II 4>{a){go, D) ^ Aa[C || D] (55) 



Objects prep( J,P,p) are defined by prep(J, P, p).L = 0. 

Objects react(J, P, p) are defined by react(J, P,p).L = ran(p), and by 
the following behavior: 



J =lli€X x{y) 



react(J,P,p) |Ugx <l>{x){<l>{z)) react(J,P,p) || T{P{z/y}) 



(56) 



Gateway objects, Wx are defined by Wx-L = {^(a:)}and by the follow- 
ing behavior: 

'CJx[C] II (/>(x)(act, n) ^ Wx[C II </>(a;)(act,u)] (57) 
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(58) 



I — j . . . j Ip l\ 3Ct 

Wx\C II <^(x)(act,u)] II (/>(x)(0 Wx\C II <A(x){act,w)] || u(0 

Let ^[-] be a context from k, and P be a DJoin-calculus process. 
Context ^[-] and process P are said to be compatible if ^[-] takes the 
form ^[-] = UJQ{U,V)[\\neU II • lla^ei/i [• • • D • • •]]> with 

4>{U) QV,U\C U, Hx set of messages of the form (p{x){act,u), u eV, 
and if P is such that FV (P) C U. 

We then have the following: 

Proposition 2 Let P and Q be two DJoin-calculus processes such that 
P —^join Q- Then, for any k context ^[-l such that ^[-] and P are com- 
patible, there is a k context ^[-], such that ^[-] and Q are compatible and 
e[Tp(p)] ->* c[T^(g)]. 

Proof By induction on the form of derivation contexts in the DJoin- 
calculus. ^ 

We can illustrate a proof step and the way the simulation works with 
an instance of the GO rule of the Djoin-calculus: 

d.b[D' : P'] A e.a[D : P\go{b)-, Q] -)> d.b[D' : P' A d.b.a[D : P\Q] 

Let R = d.b[D' : P'] A e.a[D : P\go{b)-,Q] and S = d.b[D' : P'] A 
d.b.a[D : P|Q], and let ^[-] = wq{U, F)[ r? || Ad[Ab\]] || Ae[^oO] II ‘ ]• We 
have the following derivations: 

mR)] 

= wo{U,V)[g II A4A,\\] II II \oc{d.b,D',P') || loc(e.a, P, P || go(6);Q)] 

MU,V)[n II A4A4T{D') II T(P')]] II A4A4T{D) II T(P) || go(6,Q)]]] 

^ wo{U, V)[r, II A4A4T{D') || T(P')]] || A44>{b) <go, A4T(D) || T(P) || T(Q)])]] 

-> uo{U, V)[r, II A4A4T{D') || T(P')]] || <j>(b){go, A4T{D) || T(P)] || T(Q)) || AeQ] 
uJo{U,V)[r, II A4A4T{D') || T(P')] || mi90,A4T{D) || T(P) || T(Q)]>] || A,\\] 
^ MU,V)[g II A4A4T{D') || T(P') || A4T{D) || T(P) || T(Q)]]] || A,\\] 
MU,V)[n II >ld[>l6[>laD]] II AeD II loc(d.6,P',P') II loc(d.6.a,P,P II Q)] 

= i[T{S)] 



4.3. DISCUSSION 

The simulations presented above are very similar in their form: apart 
from objects performing ancillary functions (global container objects 
which are used essentially to implement name management in the simu- 
lated proces calculus, and gateway objects which are used to implement 
message exchange with non unique receivers required by the simulated 
process calculus) , the core of each simulation lies in the definition of a 
particular type of container objects (objects >1“ and rules (28) to (35) 
for ambients, objects Aa and rules (50) to (55) for DJoin localities). 
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This suppports our claim that the essential difference between these dis- 
tributed calculi lies in the behavior they implicitly attach to their specific 
notion of domain and which is precisely characterized by the k model 
simulation. Additional evidence for this claim can be found in [18]. 

5. CONCLUSION 

We have presented in this paper the k model, a general model for 
distributed and mobile computation, based on a notion of domain. 

The work undertaken here is far from complete, however. First, two 
important requirements are currently not covered by our model : the 
ability to define domains with overlapping contents, and the ability to 
create new domains by combining existing ones (see [18] for a discussion). 
To meet these requirements, one would require complementing the k 
model with general rules for the combination and the composition of 
domains. 

A second direction for further research resides in the definition of 
an effective programming model based on the k model. We are cur- 
rently investigating the extension of the blue calculus introduced in [3] 
with constructions based on domains. Armed with such a domain-based 
process calculus, we would then be in a position to further develop the 
theory of distributed domains, relying on standard process calculus tools 
such as bisimulations and type systems. 

A third line of investigation lies in the systematic comparison of mod- 
els and calculi for distributed programming. Apart from the Mobile 
Ambients calculus and the DJoin calculus, we have successfully sim- 
ulated the 7Ti/-calculus [1], in the k model (see [18]). We believe the 
Seal-calculus, as defined in [22], the D7r-calculus, as defined in [8], or 
the Safe Ambients calculus introduced in [11] can be simulated in much 
the same way. Equipped with a full-fiedge domain-based process cal- 
culus, we could certainly get stronger results than those reported here, 
e.g. along the lines of fully abstract simulations up to given execution 
contexts. 

The K model, as defined in this paper, is certainly too powerful for 
programming purposes. Studying how different distributed process cal- 
culi can be simulated with it, can provide us with useful hints towards 
the definition of a domain-based process calculus which can subsume 
them and accommodate them as sub-calculi. 
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Abstract In this paper we introduce a formal approach for the specification of 
mobile code systems. This approach is based on graph grammars, that 
is a formal description technique that is suitable for the description of 
highly parallel systems, and is intuitive even for non-theoreticians. We 
define a special class of graph grammars using the concepts of object- 
based systems and include location information explicitly. Aspects of 
modularity and execution in an open environment are discussed. 

Keywords: Mobile code. Formal specification. Graph grammars 

1. INTRODUCTION 

The fast and continuous evolution of computing and communication 
capabilities have resulted in massively distributed computational envi- 
ronments (e.g. Internet). These environments are often called open 
environments and are characterized by: massive geographical distribu- 
tion; highly dynamic environments; no global control; partial failures; 
lack of security and high heterogeneity due to the diversity of commu- 
nication links (delay, throughput), cooperating organizations, services 
offered, etc. Due to these factors, developing applications for such en- 
vironments is rather complex and therefore research efforts have been 
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directed to improve support for development of distributed applications. 
One such efforts is the research area around code mobility[9]. 

In traditional distributed systems, interacting components are pri- 
marily static, i.e., a component remains on the same location during its 
whole life-cycle and interactions with other components take place by ex- 
changing messages through the communications network. Code mobility 
can be defined as the capability of dynamically changing the location of 
an executing component. A mobile component is able to stop its exe- 
cution on a location, migrate through the network carrying its internal 
state, and resume its execution on another location. Migration is not 
transparent to the distributed software developer, it is instead explicitly 
handled by him/her as part of the application’s functionality. 

A wide field of applications is foreseen to be scenario for mobile code 
applications. Network management [9], electronic commerce [18], dis- 
tributed information retrieval [10], advanced telecommunication services 
and active networks [28], active documents and workflow management 
systems are among them. Code mobility is also well suited for the ever 
growing field of physical node mobility because it is possible to launch 
remote computations, switch off the local node (e.g., a laptop), switch 
on the node latter, and receive the results of the remote computations. 

The ideas around mobile code and its implementations emerged from 
a practical approach. Most of the standards, platforms and languages 
currently available and widely used for the development of this kind of 
systems[22] reflect this fact: they were constructed in an ad hoc way 
rather than based on corresponding theoretical investigations. Start- 
ing with the TT-calculus [19] [21], there had been some efforts towards 
computational models for mobile systems, e.g. based on abstract state 
machines [17], on mobile ambients [3], and on actors [2]. However, to 
be used in practical applications, high-level specification languages as 
well as programming languages whose semantics can be described using 
such models must be provided. There are some proposals of correspond- 
ing programming languages (e.g. KLAIM [6], Mobile UNITY [25], Piet 
[23], Nomadic Piet [29]), but on the level of specification there is still no 
formal method that is largely used for mobile systems. When consid- 
ering mobile code systems, complex distribution aspects, like location 
and mobility, communication, and, in some cases, failures, are not only 
implementation issues but also part of the functionality of the system. 
Therefore, it is necessary to provide the user with abstract constructions 
to specify and reason about those aspects. Process calculi models and 
corresponding languages offer a level of abstraction based on processes: a 
system is viewed as a composition of (interacting) processes. Although 
this point of view may be adequate for some aspects of a system, it 
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lacks a comprehensive representation of data structure and its distribu- 
tion within a system. Object-based models, instead, join descriptions of 
data and processes within one object. In such systems, distribution and 
concurrency appear naturally with the concept of objects as autonomous 
entities. In the practice, object-based approaches to specification and 
programming are widely accepted, although most of the specification 
methods used are informal of semi-formal. In this paper we advocate 
the use of a formal description technique, namely graph grammars, to 
specify mobile code systems. 

Graph Grammar [8] [ 26 ] is a formal specification formalism that has 
been already used for the specification of concurrent and distributed sys- 
tems [ 27 ] [ 24 ]. The basic idea of this formalism is to model the states of a 
system as graphs and describe the possible state changes as rules (where 
the left- and right-hand sides are graphs). The behavior of the system 
is then described via applications of these rules to graphs describing the 
actual states of a system. Rules operate locally on the state-graph, and 
therefore it is possible that many rules are applied at the same time. 
In [ 20 ] is was shown that it is possible to encode any vr-calculus agent 
into a graph grammar. There, vertices were used to model channels 
(or names) and (hyper)arcs were used to model processes, thus obtain- 
ing a graphical representation of a term (agent). The reduction rules 
were then described by graph rules. Using this graph representation, it 
was possible to provide a true concurrency semantics to the 7r-calculus. 
Note that there the description of the system is given by one graph, 
the rules were just used to implement the reduction of the vr-calculus. 
Here we will adopt an approach in which the system will be modeled 
by a graph grammar, the initial state of the system will be modeled 
by a graph (representing the distributed structure of data/objects) and 
possible evolutions of the system will be described by a (user-specified) 
set of rules. Graph grammars are appealing as a specification formalism 
because they are formal, they are based on simple but powerful concepts 
to describe behavior, and at the same time they have a nice graphical 
layout that helps even non-theoreticians understand a graph grammar 
specification. The latter argument was of particular importance for our 
choice of using graph grammars as a specification formalism for mo- 
bile code systems because it helps for a good acceptance of a method 
in practice. To make our specification language simpler to use within 
this application domain, we will define a special clauss of graph gram- 
mars using the concepts of object-based systems and include location 
information explicitly. 

In Sect. 2 we recall the main concepts of graph grammars according 
to the algebraic approach [7] and introduce the concept of doubly-typed 
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graph, that will be used to model object-based and mobile systems. 
In Sect. 3 we show how to describe mobile code systems using graph 
grammars, and in Sect. 4 we discuss (informally) the semantics of such 
systems. Final remarks can be found in Sect. 5. 

2. GRAPH GRAMMARS 

Graphs are a very natural means to explain complex situations on an 
intuitive level. Graph rules may complementary be used to capture the 
dynamical aspects of systems. The resulting notion of graph grammars 
generalizes Chomsky grammars from strings to graphs. A graph gram- 
mar is composed by a type graph (representing the types of vertices and 
edges allowed in the system), an initial graph (representing the initial 
state of the system) and a set of rules (describing the possible state 
changes that can occur in the system). 

We will use the algebraic Single-PushOut (SPO) approach to graph 
grammars [16] [7]. This approach is based on categories of graphs and 
partial graph morphisms. The kind of graph we will use is called doubly- 
typed graph. In this Section we will first present the definition of doubly- 
typed graphs and (partial) morphisms, and then show how the use of 
this kind of graphs allows for a nice description of object-based systems. 
Then, in Sect. 3 we will expand this model for mobile code systems. We 
assume the reader is familiar with basic notions of category theory. 

2.1. BASIC NOTIONS 

Graphs and homomorphisms: We will consider graphs with vertices la- 
beled by attributes, that are values belonging to carriers sets of an alge- 
bra [15]. A graphs is a tuple G = (V^E^A^s^t^a) consisting of two sets 
V and E (vertices and edges), one algebra A (attributes) and three total 
functions s^t \ E ^ V and a : V U{A) (source and target of edges, 
and the attribution function), where U {A) is the disjoint union of carrier 
sets of A. A homomorphism g : G ^ H is a. triple g = {gv->9E’>9A) con- 
sisting of two partial functions gy and gE mapping vertices and edges 
from G to if and one total algebra homomorphism gA mapping the 
attribute algebra of G into the attribute algebra of H such that the dia- 
grams below commute (the diagram on the left represents two diagrams, 
one for the compatibility with the source and other with the target 
functions). Let GraphP be the category of graphs and morphisms as 
described above (for the formal definition see [15], [14]). Colimits in 
GraphP can be constructed componentwise in the categories of sets 
and of algebras followed by a construction to remove edges whose source 
or target vertices have been deleted. For details see [14]. 
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Notation 2.1 The <-^-arrows denote total morphisms, whereas -^-arrows 
denote arbitrary morphisms (possibly partial). For a partial function f , 
dom{f) represents its domain of definition, /? and /! denote the cor- 
responding domain inclusion and domain restriction. Each morphism g 
in the category GraphP can also be factorized into corresponding com- 
ponents g? and 5!. 

Typed Graphs and morphisms: A typed graph is a tuple = 
{G, type^, T) where G and T are graphs and type^ : G T is a, total 
graph morphism. A typed graph morphism g^ : G^ between 

typed graphs G^ and is a pair of graph morphisms g^ = {g,idT) 
with g : G H and idx is the identity on T such that type^ o g? = 
type^ o g\. A typed graph morphism g^ is called an injective/total 
if g is injective/total. The category of typed graphs and typed graph 
morphisms over a type graph T is denoted by TGraphP(T). Colimits 
in TGraphP(T) can be constructed componentwise in GraphP [14].^ 
Doubly-Typed Graphs and morphisms: As the definitions and results for 
doubly-typed graphs are analogous to the ones for typed graphs, we will 
just sketch them here. To get the category of doubly-typed graphs, one 
has just to take the corresponding definition of typed graphs and sub- 
stitute the category GraphP by TGraphP(T). A doubly-typed graph 
{G^ ,type^^ ,TG^) will be denoted by , The graph TG is called 

(application) type-graph and the graph T is called model type- 
graph (these names will be motivated in Sect. 2.2). Again, colimits 
are constructed componentwise in the basis category, i.e., TGraphP(T) 
(see [24] for the proofs). 

2.2. OBJECT-BASED GRAPH GRAMMARS 

In this paper we consider an object-based system as being a system 
consisting of autonomous entities called objects that communicate and 
cooperate with each other through messages. Objects may have an in- 
ternal state and relate to other objects within the system. The behavior 



^If we had used total graph morphisms, the category defined above could have been defined 
as a comma category (as it was done in [4]). We use an analogous construction for categories 
with partial morphisms called generalized graph structures [14]. 
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of an object is described through its reactions to the receipt of messages 
(triggers). This reaction may be to change the object’s internal state 
and/or send messages to other objects. An object may perform many 
(re) actions in parallel. 

A way to model object-based systems using graph grammars have 
been presented [13] inspired in the actor model [1]. The basic idea was 
to use graph grammars as a (graphical) language to specify actor sys- 
tems. We will follow the same ideas, although using definitions based 
on doubly-typed graphs. 

To describe an object-based system using graph grammars, the first 
step is to identify the entities of this specification model and represent 
them as a graph, called model graph. This is shown in Figure 1. Objects, 
messages and attributes will be modeled as vertices. A message must 
have as destiny an object (modeled by the dashed edge) and may have 
as arguments other objects and/or attributes of data types. An object 
may know other objects and may have attributes. Each attribute vertex 
is attributed with a value belonging to an attribute algebra.At this level 
of abstraction, we will use a variable as attribute to describe that the 
Q-vertex may assume any value from the carrier sets of the attribute 
algebra in some instance graph of this type.^ Note that a type graph 
models kinds of objects and links that may be present in an actual state 
of the system, but say nothing about the number of elements of each 
kind that must be present at a particular state. 




Figure 1 Object Model Graph OG 



The existence of the model type-graph makes it easier to relate spec- 
ifications based on different models: once we have related the models 
at the abstract level (for example, via a morphism between two model 
type-graphs) we can relate specifications of concrete applications based 
on that models. 



^This can be formally described, for example, by using as attribute algebra a term algebra 
over an order-sorted specification. As this topic is not central for this paper, we will not 
discuss it in detail. 
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For each specific object-based system we may have various types of 
objects and messages that are relevant for that application. Thus, to 
build a specification for an object-based system using graph grammars 
one must define the application type-graph. In the next section, Figure 
2 shows the model type graph for mobile code systems, and Figure 5(a) 
shows the application type graph corresponding to one specific mobile 
code application. 

A rule r : L R specifies a state change of a system in the following 
way: all items that are in L must be present at the current state to 
allow this state change, all items that are mapped from L to R (via the 
morphism r) will be preserved, all items that are not mapped from L 
to R will be deleted from the current state and all items that are in R 
and are not in L (not in the range of r) will be added to obtain the 
following state. For an object-based graph grammar we will only allow 
rules that consume elements of type message, i.e., each rule represents 
a reaction to the kind of message that was consumed. Moreover, only 
one message may be consumed at a time by each rule. Note that the 
system may have many rules that specify reactions to the same kind 
of message (non-determinism), and that many rules may be applied in 
parallel if their triggers (messages) are present at an actual state (graph). 
Many messages may be generated in reaction to one message. To make 
sure that a rule may be applied whenever its trigger is found in the 
actual state graph we will require that whenever a message appears in a 
graph, it has exactly all specified arguments and exactly one destination. 
Analogously, each object must have all its attributes. 

The following definition is given in a semi-formal way because the 
corresponding formal definitions require a number of concepts that are 
not needed elsewhere in this paper and have been omitted. 

Definition 2.2 Rule. Let be a finite typed-graph, where OG is 

the object-based model type-graph. A morphism r : — > jiAG/^OG 

is a rule scheme iff L and R are finite and r is injective. A rule is a 
rule scheme which satisfies the following conditions: 

i) There is exactly one message vertex on the left-hand side of a rule. In 
this case, m is called trigger of r, denoted by Trig{r). 

ii) The message on the left-hand side of a rule is consumed by the appli- 
cation of the rule [Trig{r) ^ dom{r)). 

iii) Messages have exactly one destination and all necessary arguments. 
This is called message-completeness. Moreover^ all items in L must 
be connected. This latter condition is to avoid non-local side effects. 

iv) Only the attributes corresponding to the internal state of the desti- 
nation of a message may appear in L and R. 
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Given a rule scheme rs and a rule r, a specialization is a pair of 
total homomorphisms (left^ right) mapping the left- and right-hand sides 
of the rule scheme rs to corresponding left- and right-hand sides of one 
of the rule r such that r o left = right o rs. 

Now we can define a graph grammar. 

Definition 2.3 (Object-based) Graph Grammar. A graph gram- 
mar is a tuple GG = (AG^^ ^ I ^ Rules) where OG is the object-based 
model graph, AG^^ is a finite typed-graph, called the type of the gram- 
mar, I is a finite, message-complete, object- complete (each object has 
exactly all attributes specified in AG^^) doubly typed-graph according to 
AG^^, called the initial graph of the grammar, and Rules is a finite 
set of rules according to AG^^ . 

Notation 2.4 When the model graph OG is clear from the context, we 
will write G^^ instead of . 

3. MOBILE CODE SYSTEMS AS GRAPH 
GRAMMARS 

With Mobile Code, the distributed software developer can build appli- 
cations taking location into consideration. Migration is not transparent, 
but rather specified explicitly. In order to discuss mobility, some notions 
have to be first established. The distributed environment is assumed to 
be a set of places and a set of mobile components. 

Places work as possible locations where mobile components can run. 
They offer basic facilities and the possibility of accessing other compo- 
nents having well defined interfaces (e.g. naming service, event service, 
etc.). Basic facilities are communications, storage, and processing power. 
The basic functionality of a place is to accept an incoming mobile com- 
ponent, launch it and support it during run time until it leaves. 

Mobile components are software components that may migrate during 
their execution from place to place to use other local components and 
basic facilities. A mobile component has internal data or state, code, 
and a set of meta-data or attributes (e.g. identifier, credentials, origina- 
tor, operational status, etc.). These components are designed without 
location transparency and may create other mobile components to run 
concurrently in the same or different places. Mobile applications can be 
build from various mobile components. 

Example 3.1 As an example of a mobile code application, consider shops 
that support places to which mobile components can move to and from. The 
place of each shop can be configured following its objectives, with services 
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relative to the shopping activity, e.g., to answer queries about offers and 
prices, to reserve and sell products or services, etc. 

Consider that various shops exist in the distributed environment and that 
a user wants to know which shop has the cheapest price for a product. 
Various approaches can be followed to achieve that. Here we adopt a simple 
one based on mobile code. 

The user launches a mobile component informing a list of shops (ad- 
dresses of the places of the different shops) and the product to search for 
(details of how to obtain those place addresses will not be considered here). 
The component sequentially visits the various places informed by the user, 
and in each place interacts with a query service of that shop to discover the 
price of the product informed by the user. After visiting all places defined 
by the user, the component returns to the origin place and informs the user 
where the cheapest price for the desired product was found. 

We can model mobile code systems as object-based systems having two 
kinds of objects: places and components. The specification of places sug- 
gested here will encompass only the functionalities that must be provided 
by a place (and can not be implemented as components). Everything 
else will be seen as a component. Obviously, some of these components 
may implement the services provided by the place, and some may be user 
defined applications executing on that place. This way we will get a fiex- 
ible model that can be seen as a first step towards a formal specification 
of active networks: services of a place may be upgraded dynamically 
without having to recompile or make changes to the kernel of the place. 

A component may send messages to other components it knows and 
also to its own place (for example, requesting to move somewhere else). 
Plaoes may send messages to the components lying on it and to other 
places. But if we analyze carefully, we recognize that places have the 
power to act over components: messages among components can only be 
sent if the corresponding places agree, the same holds for move requests; 
if a place crashes, all components running on it are not accessible any- 
more and stop execution (if the place has recovery schemes, components 
may resume when the place re-initiate, otherwise, the components dis- 
appear) . Moreover, the attribute describing in which place a component 
is in can not be changed by the component itself (like its object iden- 
tity). As we wish to have a high-level specification language for mobile 
code systems, we will abstract from this kind of details. For example, a 
move will be modeled as an atomic operation in which a place is able to 
modify the argument of a component that corresponds to its placement 
information. Figure 2 shows the graph that will be used as model type 
graph to mobile code applications. The axe labeled with isJn carries 
the information about the place a component resides. This argument 
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will be mandatory for each component of a mobile code system spec- 
ification. The arcs labeled with to indicate the receiver of a message. 
In an instance of type Msg the only outgoing arc shall be of kind to 
because each message in the system must have exactly one receiver, and 
the ingoing arcs represent the parameters of this message (that, accord- 
ing to the model type graph MG may be places, components and/or 
attributes). The outgoing arcs of components and places represent their 
internal state. The arcs/ vert ices are labeled/have diflFerent shapes such 
that we can distinguish the instances of them without having to show 
explicitly the typing morphism. 




Figure 2 Mobile Code Model Graph MG 

As we may see components and places as objects, we can define rules 
and graph grammars for mobile code systems analogously to the corre- 
sponding definitions for object-based systems (Defs. 2.2 and 2.3), obtain- 
ing the concept of mobile code graph grammars. In this case, we would 
have to relax condition v of Def. 2.2 to allow the deletion/insertion of 
isJn attributes of components by the places they are in. 

When designing a mobile code system, a user specifies components. 
This specification is based on his/her expectations about the behavior 
of the places involved (because places are responsible for handling com- 
munication and move requests). Thus, it is imperative that he has an 
abstract and precise description of this behavior. In the following we 
will provide such a description, and then show how (mobile) compo- 
nents may be specified using graph grammars and illustrate this by an 
example. 



3.1. SPECIFICATION OF PLACES 

A place basically provides physical resources (like memory, CPU) and 
communication services to the components running on it. Internally, a 
place manages the resources and communication, that is, it implements 
a network operating system. There are two kinds of communication that 
involve places: communication between components and places (place — > 
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component: messages to start and finish execution, etc.; component — > 
place: messages to move, find place name server, etc.), and communi- 
cation between places (messages that form the communication protocol 
between places). 

The resources and their administration can be modeled very abstractly 
using an algebraic specification. One of the operations, accept : State^ 
ReqList Bool^ may evaluate whether the place may or may not accept 
a new component trying to move to it (based probably on the number 
of applications actually on this place, the properties of the place and the 
requirements of the component). 

Communication can be modeled using graph rules. Figure 3 presents 
rule schemes to model this, actual communication will be represented 
by a rule that is a specialization of one of these rule schemes. Rule 
scheme Send specifies that components lying on the same or different 
places may communicate (note that this rule scheme specifies local and 
remote message passing, since the specialization homomorphism is not 
required to be injective). Rule scheme ServiceRequest describes that 
components may send messages to the place in which they are executing. 




Figure 3 Message Passing Rule Schemes 

Besides computational resources and communication, a place may be 
able to provide move services. The rules describing such service are 
shown in Figure 4. Message Move can be sent by a component to a place 
(Orig) asking to do a move to place Best. The attribute req represents 
the requirements of the component. This is a list of services/attributes 
needed for the execution of this component. When a place {Orig) re- 
ceives a Move message from a component, it sends a MoveReq message 
to the place that shall receive the component having as attributes the 
component that wants to move, its requirements and the origin place 
(rule RequestMove). Rule Move specifies what happens when a place 
receives a MoveReq message and decides to accept the component^: 



^The condition written under the rule arc describe conditions that has to be satisfied for the 
rule to be applied. Formally this behavior is obtained by considering as attribute algebra for 
the left- and right-hand side an algebra that satisfies this condition. 
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the place sends a message to place Orig to inform that the component 
Compl has successfully moved, sends a message to Compl telling it to 
continue its execution, and changes its internal state to include this new 
component. Messages Deny Move and NotMove specify the actions to 
be performed when a move request does not succeed: the destination 
place informs the origin place the move was denied, and the latter for- 
wards this information to the corresponding component. 
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Figure 4 Move Rules M Rules 



3 . 2 . SPECIFICATION OF MOBILE 
COMPONENTS 

To build a specification of a mobile component, the first step is to 
define the application model graph AG to be used. This graph will 
be typed over the mobile code model type graph MG (Figure 2) and 
contains the types of components that are necessary for this applica- 
tion, the messages that are exchanged, and the internal structure the 
component being developed. Then we can define the initial state of the 
component (that is a doubly- typed graph over AG^^)^ and the set of 
rules that describe how this component may evolve. These components 
typically rely heavily on message passing, and therefore the behavior of 
the application can be suitably described by graph rules [24] [11]. To be 
able to model mobile code systems faithfully, this grammar must fulfill 
additional requirements: each component vertex must be connected to 
exactly one place by an is-in arc, and each rule that generates messages 
must be a specialization of one of the rules of Figure 3 (because these 
rules describe the possible message passing strategies of the places). 

Each component in an open system may use other components and 
be used by them. When choosing a component to perform some task, it 
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is important that the behavior of this used component is in accordance 
to the desired by the user component. To model this we will include in 
the specification of a component an abstract description of the desired 
behavior of the components that are used by this component. This will 
be called import interface. 

Definition 3.2 Mobile Component. A mobile component is a tuple 
MC = (T., Ini, Rules, Imp) where {T, Ini, Rules) is a graph grammar 
with type graph , Imp is a set of rules over such that the 

following conditions are satisfied: 

i) Each component vertex must be connected to exactly one place by an 
isJn arc. 

ii) Each rule that generate messages must be a specialization of one of 
the rule schemes of Figure 3. 

Hi) Each rule in Imp contains no attributes for places or components. 

Example 3.3 Now example 3.1 wilt be modeled using graph grammars. 
The application type graph (see Figure 5(a)) shows the types of entities in- 
volved. A mobile component (MC) searches for the best Price of a product 
with name given by prodName in a number of places numPlaces. MC 
holds also registers to each place to be visited (visit), to the origin place, 
to where it is — in currently, and to the place with the best offer. The sce- 
nario described also involves information services (ISs) that the MC may 
use ( consult) during its Journey. Details of IS are not given here. When 
MC completes its task it should also give back an answer to the user U. 
The identifiers real, natural and string stand for variables of the corre- 
sponding data types (we use a term algebra as attribute algebra). Actually 
all messages (together with their arguments) involved in this application are 
also part of the application type graph (although not drawn in Figure 5). 

The initial graph shown in Figure 5(b) is one of many possible initial 
graphs for this example. In this case MC will look for the best price of 
product productl in places PI to P3, departing from P.orig. In each of 
these places there are ISs located, which MC can use. 

Figure 6 shows the rules that describe the dynamic behavior of the sys- 
tem. Considering the initial state described above, the first rule that will 
be applied is rule MoveNext. This rule can be applied in three different 
ways, depending on the place chosen to be visited. In the graph grammar 
semantics (that will be discussed in the next section), this choice is non- 
deterministic. The application of this rule will generate a Move message 
having as argument the place chosen to be visited. The reader may verify 
that now rules MoveNext, QueryPrice andUpdateScProceed or Proceed 
will be applied until there are no more places to visit. Note that rules that 
belong to the specification of places and other components, for example. 
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Figure 5 (a) Application Type Graph - (b) Initial Graph 



IS, were not described here. The move rules belong to the basic functional- 
ity offered by places. The import rules for this component(not shown here) 
would describe, for example, that in response to a cost? message the IS 
component will eventually deliver a price message. 




Figure 6 Rules 



4. SEMANTICAL ASPECTS 

The behavior of a graph grammar is given by the applications of rules 
to graphs representing the actual states of the system, starting from the 
initial graph. The applications of rules may occur in parallel if the rules 
do not try to delete the same items. Note that, if a rule preserves an 
item that is deleted by another rule, these two may occur in parallel. 
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This situation corresponds to one write and one read access occurring 
at the same time. 

To be able to apply a rule to a graph representing the actual state of 
a system one must first find out whether the rule can be applied. This 
is done by finding a match of the left-hand side of the rule in this actual 
graph. An application of a rule in a graph, called derivation step^ deletes 
from the actual graph everything that is to be deleted by the rule and 
adds the items that shall be created by the rule. 

Definition 4.1 Match, Derivation Step. Let r : -> be a 

rule and be a (doubly-typed) graph. A match of r in G is a total 
doubly-typed graph morphism m : . A derivation step of 

a rule r at match m, denoted by G H, is the pushout of r and m 
in the category DTGraphP(AG^^). 

The semantics of a graph grammar can be defined as the class of all 
computations that can be performed using the rules of the grammar 
starting with the initial state. These computations may be sequential 
or concurrent, giving raise to sequential and concurrent semantic mod- 
els. Figure 7(a) Illustrates a sequential derivation for a grammar with 
starting graph I. In this derivation we have a total order (<) on deriva- 
tion steps (si < s2 < s3) that denotes the sequence in which they 
have occurred in this computation. If we make a suitable gluing^ of all 
intermediate graphs of this derivation, we obtain a structure called con- 
current derivation (Figure 7(b)). Now, the total order that existed in 
the sequential derivation is lost, but we may define a partial order (^) 
between the steps that describes the causality relation: if si ^ s2 then 
si must occur to allow the occurrence of s2. A concurrent derivation 
can be seen as an equivalence class of sequential derivations (all possible 
sequential derivations corresponding to the totalizations of ^ are in this 
class). A true concurrency semantics for graph grammars can be also 
described by an unfolding construction that gives us a partial order of 
derivation steps [24]. The unfolding construction encompasses informa- 
tions about all possible computations that are described by the given 
graph grammar. 

Open systems are highly dynamic, in the sense that places and ser- 
vices may be created, deleted, become reachable and unreachable at any 
moment. Thus, a suitable semantics for such systems must take these 
characteristics into account. Note that, to define a semantics for a mobile 
component, it is not enough to consider the behavior of this component 



'^This gluing is actually a colimit of a diagram in the category of doubly- typed graphs [ 14 , 24 ]. 
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Figure 1 (a) Sequential derivation (b) Concurrent Derivation 



in every possible network configuration, but we must also consider its 
behavior in changing network configurations, that is, in a configuration 
that may change while the component is executing. To capture the 
dynamics of the environment we will use a set of rules that describes 
such changes. Some of these rules are depicted in Figure 8. Rules 
createPlace/createComp and destroy Place /destroy Comp are used to 
create and delete places between places/components from the network. 
Moreover, a rule that changes (consistently) the internal state of a place 
is needed. The semantics of a mobile component shall consider not just 
the rules that describe the behavior of the component itself, but also and 
the rules that describe (abstractly) the behavior of the used components 
(described in the Import interface of this component), the move rules 
of the place, and the rules that may create/destroy /modify places and 
used components. As a mobile component only uses the kinds of com- 
ponents that are described in its specification, the fact that other kinds 
of components may exist in the network are irrelevant for its behavior 
and must therefore not be considered. With these rules we may obtain 
all possible computations of this system taking as initial state a graph 
consisting of the initial graph of the definition of the component itself 
plus an initial state for the places involved. We can consider a trivial 
initial state because other possible initial states may be obtained by the 
dynamic rule that changes the state of places. 
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Figure 8 Dynamic Rules 
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5. CONCLUSION 

In this paper we have introduced a formal approach for the specifica- 
tion of mobile code systems. This approach is based on graph grammars, 
and the main idea is to model places and components as vertices (with 
attributes), and their behavior as rules specifying the desired actions 
that shall be performed when a place/component receives some kind of 
message. Graph grammars seem to be well suited for the specification 
of such systems as they match a series of important characteristics: 

Concurrency: Applications are composed by various mobile compo- 
nents which may be active. Therefore a mobile application is inherently 
concurrent. Graph grammar is a formal description technique that is 
suitable for the description of highly parallel systems. Concurrency is 
not specified explicitly, as, for example, in process calculi, but rather ob- 
tained as a consequence of independence of actions (rule applications). 
As discussed in [20], this approach can be useful to guide an efficient 
implementation of the system (since it allows to derive information con- 
cerning the maximal parallelism taking into account the use of shared 
data), as well as allow for better strategies to debug a system (since it 
permits to trace back all the actions that have influenced the occurrence 
of an undesired state). Prom the concurrency semantics of a graph gram- 
mar we can obtain causal dependency and conflict relationships that can 
be used to reason about the parallelism of a system (actually, due to the 
possibility of read-access to items, we need also a third relationship, 
called weak -or asymmetric- conflict [12]). Even without considering 
all computations of the semantical model, an analysis of the potential 
causal and conflict relationships among rules may already lead to useful 
statements about the system. 

No global state: As the environment is very dynamic, mobile code 
components rely less on a global notion of state and more on a local 
notion of state, tending to have more autonomy to decide the actions to 
perform in a wider range of situations as if compared to fixed systems. 
This is naturally modeled with graph grammars as the distributed state 
is modeled by a graph and each rule application affects only a part of 
this graph (rule applications have only local effects). The description 
of the state as a graph highlights the relationships among the compo- 
nents (since these can be explicitly represented as edges connecting the 
involved components). Such a representation considerably eases the un- 
derstanding of the specification. 

Openness: In the massively distributed environment considered, places 
can be created and deleted (shut down) following policies from different 
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organizations and offer different sets of services. Components have in- 
dependent life-cycles and enter and leave places, becoming reachable or 
unreachable to other components. These dynamic aspects were consid- 
ered by the discussion about semantics in Sect. 4. 

Fault tolerance: As the environment considered is a massively dis- 
tributed one, partial failures may be present /arise. Many times it is 
important /necessary to consider the possibility of infra-structural fail- 
ures in the applications. As the sketched semantical model takes into 
consideration that the environment may fail, we believe that it will be 
possible to reason about the fault tolerance aspects of a component by 
analyzing the computations of the corresponding graph grammar. This 
is a very interesting subject of future work. 

Modularity: While modeling applications for open systems it is very 
important to have a sound definition of the functionality offered by the 
application and used from other applications. In our approach this was 
(partially) considered using the notion of import interface, which is part 
of the specification of each component. However we still have to con- 
sider the impact of this interface in defining semantical models for mobile 
applications (here we have only discussed the semantics of one mobile 
component). Moreover, it is also important to have an export interface 
describing the services offered by a component at an abstract level. This 
would require a notion of satisfaction of a specification (rule) by a graph 
grammar, that is, we would have to guarantee that the rules specify- 
ing the behavior of a given component would always lead to a certain 
state/trigger some message. This topic is currently under investigation, 
as it is also needed to assure that an imported component presents the 
required behavior. Some work in this direction have been done in [20], 
where different notions of observational equivalences for graph grammars 
were defined. Another topic would be to consider whether richer place 
hierarchies, as provided by mobile ambients [3], can be integrated to our 
approach to improve the structuring of the system. 

In addition to all those aspects, graph grammars are intuitive even 
for non-theoreticians. Besides being an unambiguous description of the 
system, a graph grammar allows for formal analysis of properties of 
this system, like complexity (for example, in terms of number of rule 
applications necessary to perform some task), relationships (causality, 
conflict) among rules, etc. In the project FLATUS [5] an environment 
for simulation of graph grammar specifications is currently under devel- 
opment. This environment may be used for the specification of mobile 
code systems as described here. 
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Abstract The ATF Calculus is a kernel language for wide-area network programming 
languages, with atomic failure semantics as its central organizing principle. 

Keywords: Wide-area network programming, fault tolerance, atomic failure. 

1. INTRODUCTION 

Programming wide-area networks has emerged as an important area of re- 
search, with the exploding commercial interest in WANs for electronic com- 
merce. While programming local-area networks has been a focus of research 
for many years, the characteristics of WANs emphasize different issues and 
potentially require different solutions. One fundamental difference is that, for 
security reasons, WANs are partitioned by firewalls into administrative domains. 
Any application that spans such administrative domains must somehow navi- 
gate the firewalls that enforce the partitioning. This difference is so fundamental 
that it has been argued that it calls for a wholly new model of computation for 
progrannning WANs [7]. Although firewalls are to some extent becoming obso- 
lete because of encrypted traffic, this argument for partitioned network address 
spaces still applies in the emerging environment of virtual private networks. 

Several process algebras have been developed as the basis for new program- 
ming languages for wide-area applications. At least two of these, the Ambient 
Calculus [8] and the Seal Calculus [10], are based on the idea that networks 
are partitioned into administrative domains and applications must navigate be- 
tween these domains. These algebras have mobile computation as their orga- 
nizing principle: to cope with the problems with communication in WANs, 
they allow processes to migrate across the network, allowing an application to 
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move to a host where it needs to perform some computation. A central facet in 
both of these calculi is their support for navigating firewalls, one of the central 
motivations for wide-area network programming languages [7]. 

This paper introduces the ATF Calculus, intended as a kernel language for 
wide-area programming languages. Although taking some of its cue from the 
aforementioned calculi, the ATF Calculus takes atomic failure as its main orga- 
nizing principle. The motivation for this is that typical wide-area applications 
require some notion of coordination between geographically and administra- 
tively distributed sites. The distribution of the sites raises the possibility of 
localized site failures and network partitions, and there should be some support 
for coping with such failures. In an application involving coordination between 
several sites, it should be possible to commit or abort a computation based on 
the pattern of failxires of the sites involved in the computation. 

Transaction systems [19], and in particular nested transactions [21, 24], have 
been developed for providing the capability for atomic failures in databases 
and distributed systems. The ATF Calculus does not completely follow the 
semantics of traditional transaction systems. In particular concurrency control 
is considered as an application issue, and the ATF Calculus only considers 
support for making failure atomic. This support is based on two ingredients: 

■ Tracking of causal dependencies between computations. 

■ An operation for atomic commitment of a collection of transactions. 

In Sect. 2 we give a description of the network model underlying the ATF 
Calculus. In Sect. 3 we give a description of the process calculus describing 
programs that execute within transactions. Both of these descriptions include 
type systems for well-formed networks and transactions. Sect. 4 gives an op- 
erational semantics for the calculus. Sect. 5 gives a semantics for aborting 
and committing transactions. Sect. 6 considers an extension of the calculus 
with process mobility. Finally Sect. 7 considers related work and provides 
conclusions. 

2. NETWORK MODEL 

Traditional process calculi such as CCS [22] and the 7i-calculus [23] do not 
distinguish between processes and the medium through which they communi- 
cate; the medium is represented as just another process. The ambient calculus 
[8] does not distinguish between networks, hosts and process address spaces; 
all are represented as ambients. We find it useful to distinguish between places 
on the network (hosts and subnets) and processes, because of their different 
failure characteristics. In this section we describe our model of networks. In 
the next section we describe the processes that execute over these networks. 

Networks in the ATF Calculus are described as follows: 
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A place is an administrative domain or a host on the network. This contains a 
“soup” of processes, channels and subdomains N. is the name of the place, 
while X is a log of the actions performed at that place. For fault tolerance this 
log must be kept in stable storage. 

A channel is used for asynchronous communication between processes. As in 
the Ambient Calculus and the Seal Calculus, all communication is local within 
an administrative domain. To communicate with a remote host, there must be 
an application-level protocol for delivering a message across the intervening 
domains. As with places, a channel has a name The contents of a channel 
at a place is obtained by taking the union of the atoms representing 
messages sent to that channel at that place. Messages are a particular instance 
of transactional processes. 

A transactional process t{P} denotes a process P that executes as part of 
the transaction identified by the transaction identifier t. If that transaction is 
aborted, then all effects (messages sent and received) of that process must 
be undone. Transactional processes t{P} reflect the fact that all application- 
level computations in the ATF Calculus take place within a transaction. The 
transaction name t identifies the transaction within which a process executes 
(f{P}). Multiple threads may execute within a transaction; if one thread aborts 
in a transaction, then all effects of all threads in that transaction are undone. 
Thus transactions are the mechanism for defining the granularity of failures in 
the ATF Calculus. 
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2.1. NETWORK TYPE RULES FOR ATF 

The type rules for the network are described by the following type rules, 
using judgements of the form r\- N net where T is a context of named types 
{n:NT). 



r h TV net r h X log (nP‘ : Place) G T 
r h «P‘[X,TV] net 



r h ATi net 


r 1- TV 2 net 


TH(iVi 1 


N 2 ) net 


ru{( 


n : NT)] \-N nut 


r h {new n : NT)N net 


{t : Trans) G I 


' ri-P:() 


rhr{P}net 




r h AT net 




n-ATlog 


r 1- Xi log 


ri-Xsiog 



r h Xi ; X2 log 



(Net Place) 
(Net Wire) 
(Net New) 
(Net Process) 
(Log Net) 
(Log Extend) 



There is a further side-condition, that we do not explicitly enforce here for 
economy: All transactional processes for a particular transaction t must execute 
at the same place. This is because various decisions regarding committing 
and aborting transactions are made based on information in the logs, and so 
for scalability it must be possible to obtain this log information at a single 
local place. Note that it is not sufficient to say that there is a mapping from a 
transaction identifier t to the name of the place «p* on which all processes in that 
transaction execute. This is insufficient because we do not require that every 
place has a unique name (for example, network address translation in VPNs 
would make this an unrealistic assumption). 



3. TRANSACTIONAL PROCESSES 

Processes in the ATF Calculus are described by: 



P€ Process ::= send{M,V) Message Send 

I receive {M,F,P) Message Receive 
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F € Cont 



crypt{M, V, F) Packet Encrypt 

decrypt{M, V, F) Packet Decrypt 

F{V) Continue 

let {x^) =V in P Elim Tuple 

\P Replication 

(^1 I ^ 2 ) Parallel Composition 

{new n : NT)P New Name 

commit Commit transaction 

abort Abort transaction 

0 Stopped Process 

{x:T)P Continuation 



The basic operations are for asynchronous message-passing [27]. In the ATE 
Calculus the essential use of mobility for navigating administrative domains is 
in the send and receive operations. For example the send operation takes two 
arguments: a capability M and a value V. The capability specifies a path to 
be taken in the network (identified by subcapabilities for leaving and entering 
administrative domains) and a capability for depositing the value in a channel 
at the final destination place. As with algebras such as the Ambient Calculus 
and the Spi Calculus [8, 1], access control is enforced by controlling the dis- 
tribution of these capabilities, which are akin to private keys in cryptographic 
infrastructures. 

Our provision for “mobility” is consistent with approaches in active net- 
works, such as the Switchware architecture [2], that restrict mobile threads to 
simplified packet languages (such as the PLAN language of the Switchware 
architecture [18]). The language of capabilities M can be considered as the 
analogue in the ATE Calculus of packet languages such as PLAN. This is in 
contrast with the Ambient Calculus and the Seal Calculus, which allow general 
user processes to migrate across the network. Active network architectures also 
allow heavyweight loading of application code modules to routers; this could 
be accomplished in the ATE Calculus by extending it to allow processes in 
messages. This is investigated in Sect. 6. 

The receive operation takes as its main argument a capability for reading from 
a channel. This operation also has two continuations: the success continuation 
F and the failure continuation P, where the latter is activated if the receive 
operation times out. We assume an asynchronous system, so timeouts provide 
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a form of unreliable failure detector which is the best that we can attain in an 
asynchronous system. 

Values in the ATF Calculus are described by: 



M,VG Value ::= nP*‘[V] Packet 

I Tuple 

I p Parameter 

I in p Input Capability 

I out p Output Capability 

I M\ M 2 Compose Caps 

Packets are an inessential aspect of the ATF Calculus, but provide crypto- 
graphic primitives for authentication and encryption of message contents as part 
of the language. Our motivation for including packets is that they are a funda- 
mental tool for WAN programming, provided as primitives in the Spi-calculus 
[1] and defined in the ambient calculus [9]. The design of the ATF Calculus 
was influenced by the need to provide a corresponding facility. 

Creating a packet requires a capability for putting a value into a packet, while 
reading a packet requires the inverse capability. Capabilities therefore provide 
a function analogous to cryptographic keys; an application may publish only a 
key for creating packets, and then be the only process capable of reading packets 
created using the capability. Separating the capabilities for message creation 
and reading, from the capabilities for delivery and receipt of messages, allows 
an encrypted message to be forwarded by a process that does not have access 
to a key for reading the message contents. 

The form of capabilities are taken from the Ambient Calculus. In the Ambient 
Calculus, places, channels and packets are uniformly represented as ambients. 
However we find it easier to treat each of these concepts differently. For fault 
tolerance purposes, the behaviour of places, channels and packets are very 
different. A capability is a sequence of subcapabilities of the form in p or out p, 
where p is a place name, channel name or packet name, with the interpretation: 



in nPi 


enter a place 


in n^^ 


write to a channel 


in nP*' 


create a packet 



out «P* 


leave a place 


out n‘^^ 


read a channel 


out nP*^ 


read a packet 



Types in the ATF Calculus are described by: 
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AT e Ambient Type 


::= Place 


Place Type 




1 Chan[T] 


Channel Type 




1 Packet[T] 


Packet Type 


NT e Name Type 


::= AT 


Ambient Type 




1 Trans 


Transaction Type 


T € Type 


::= NT 


Name Type 




1 {Tu---,Tk) 


Tuple Type 




1 Cap[AT] 


Capability Type 




1 ^ 


Type Variable 




1 pX.T 


Recursive Type 


Continuation Type 


::= r->() 


Process Type 


Ambient types are the types of place names, channel names and packet names 
(the name reflects the original inspiration from the Ambient Calculus). Types 
also include process types and capability types, where the latter are indexed 
by ambient types. Types also include recursive types. In combination with 



tuple types, this supports a polyadic sorting discipline for data structures such 
as described for the 7i-calculus [23]. 



3.1. PROCESS TYPE RULES FOR ATF 

In this subsection we consider the type rules for transactional processes. 



r h M : Cap[Chan[T]] T h V ; 7 
T^send{M,V) : () 



(Proc Send) 



As already described, the send operation has two arguments, a capability and 
a value. The capability is to allow the process to deposit a message payload 
into a channel of the same type as the type of the payload. The send operation 
generates an “active message” that navigates the network to its destination. 



T\-M:Cap[Chan[T]\ T\-F:T-a{) rhP:() 
r h receive (M,F,P ) : () 



(Proc Receive) 



The receive operation requires a capability to read the contents of a message 
channel, where the message payload has the same type as the domain of the 
success continuation F. As with the typed ambient calculus [9], the type sys- 




72 



tern does not distinguish between capabilities for sending to a channel and for 
receiving from a channel. 



T\-M:Cap[Packet[T]] rHV:r T ^ F \ Packet[T] ^ {) 
Y\- crypt{M’'^\V,F) : () 



(Proc Encrypt) 



T\-M:Cap[Packet[T]\ T b V : Packet[T] r\-F:T^{) 
r\-decrypt{M’^\V,F) : () 

(Proc Decrypt) 



The encryption operation takes a capability for creating a packet and a pay- 
load, and passes to the continuation an encrypted packet containing the payload. 
Conversely the decryption operation takes a capability for destructing a packet, 
and an encrypted packet, and passes the contents of the packet to the contin- 
uation. Again the type system does not distinguish between capabilities for 
creating and for destructing packets. 

The type rules for the remaining process constructs are fairly conventional: 



ri-F:r->() ri-P:r 
ri-F(v):() 



(Proc Continue) 



ri-P:(7i,...,rt) ru{ixi:Ti),...,{xk:n)}hP:{) 

r\- let {xi,... ,Xk) = V in P : {) 



(Proc Let) 



rHP:() 

ri-!P: 0 



(Proc Replicate) 



ru{(n:A^T)}l-P: 0 
r h {new n : NT)P : () 

ri-Pi:() rh-P 2 :() 
ri-(Pi I P 2 ):() 

rH 0 :() 



(Proc New) 

(Proc Par) 
(Proc Null) 



ru{(x:r)}hP:() 

ri-((Ar:r)P):r^() 



(Proc Cont) 



The Proc Cont rule provides the type rule for a continuation, repre- 
senting the remainder of a computation. As with almost all process algebras. 
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programs are written in continuation-passing style (a process algebra is basi- 
cally an assembly language for concurrent programming). Continuations are 
second-class; they cannot be treated as values. 

The calculus is first-order, in the sense that only simple values can be ex- 
changed between processes. The calculus could be made higher-order by mak- 
ing continuations into first-class values, essentially adding ^-abstraction to the 
language. This is a straightforward modification to the operational semantics, 
but at some cost in complicating the metatheory of the calculus. We consider 
another approach to adding process mobility in Sect. 6 . 

3.2. VALUE TYPE RULES FOR ATF 

In this subsection we provide the type rules for values, that are the content 
of message payloads exchanged between processes. 

[n^^ ■.Packet[T])eT ri-V;r 
r H nP’'[V] : Packet[T\ 
rhVi:ri ... r \- Vk:Tk 

jp-T)er 
r\-p:T 

The Val Param rule is for both names (bound by the new construct) and 
variables (bound by abstraction ((x : T)P)). A parameter can be a variable 
abstracting over a place, channel or packet name, as reflected in the rules for 
forming capabilities. 



(Val Packet) 
(Val Tuple) 
(Val Param) 



r\-p:AT 
r\- in p: Cap[AT] 



r\-p:AT 
r h out p : Cap[AT] 

r h Ml ; Cap[Place] P h M2 : Cap[AT\ 
T\-MxM2:Cap[AT] 



(Val Input Cap) 
(Val Output Cap) 
(Val Compose Cap) 



The Val Compose Cap rule types the composition of capabilities. As 
explanation for this type rule, useful capabilities have the following forms: 



in nP'', out n^^ Create or destruct a packet 
out Receive from local channel 

Ml . . . M„.in n^^ Deliver payload to channel at destination 
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where in the latter case each Mi has the form in nf or out nf for some nf, 

4. OPERATIONAL SEMANTICS 

This section provides the operational semantics for the ATF Calculus. In 
Sect. 5 we consider the semantics of committing and aborting transactions. 

4.1. LOCAL COMPUTATION RULES 

The local computation rules are fairly standard, and describe sequential com- 
putation within a process. The local computation mles are given by; 

!P (!P I P) (Red Replicate) 

receive {out n‘^^,F,P) P (Red Timeout) 

crypt{inri^^,V,F) P(nP*'[V]) (Red Crypt) 

decrypt{outn^'^,n^^[V],F) F{V) (Red Decrypt) 

let = {Vi,...,Vk) in P {Vi/j:i,...,V„/.x„}P (Red Let) 

{{x:T)P){V) {V!x}P (Red App) 

The timeout rule allows the receive operation to time out after some period 
of time. We do not explicitly represent time, since it does not contribute any- 
thing to the semantics. In a synchronous system it might be useful to have a 
representation of time in the semantics, although calculi that assume the fail- 
stop model of failures only rely on an operation for detecting whether a site 
has failed [25, 13]. As is well-known, wide-area networks constitute asyn- 
chronous distributed systems, where no upper bound can be placed on message 
transmission delays or message processing times, and there may be unbounded 
real-time clock drift between different machines [11]. Timeouts therefore con- 
stitute unreliable failure detectors where a process makes the assumption after 
some period of time that a failure has occurred. The process must be prepared 
to cope with the possibility that this assumption is erroneous. 

4.2. STRUCTURAL RULES 

The structural rules for networks and processes follow the usual style of 
“chemical” semantics for concurrent processes [6], and constitute the “heating” 
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rules that allow processes and messages to be brought together for synchroniza- 
tion. The structural rules for processes include the internal reduction relation 
for processes. We omit the obvious structural congruence rules. 

0 I N = N 
Ny I N 2 =N 2 I Ny 
{Ny I N2) \N^=Ny I {N2 I N^) 

{{new n:NT)Ny) \ N2 = {new n:NT){Ny \ N2), n^fn{N2) 
n^\L, {new n\NT)N] = {new n\NT)n^\L,N] 

{new ny:NT){new n2'NT)N = {new n2'.NT){new ny:NT)N, ny 
{newn:NT)N = N, n^fh{N) 
t{Py I = I t{P2}) 

t{{new n:NT)P} = {new n:NT)t{P} 
z\L = L 
L\z = L 

Ly\{£j 2 \Lii) = {Ly\Lo)\Li 
0 I P = P 
Py I P 2 = P 2 I Pi 
(Pi I P2) I P 3 =Pl I (P2 I P3) 

{{new n:NT)Py) \ P2 ^ {new n\NT){P\ \ P2), n^jh{P2) 

{new ny :NT) {new «2 ■NT)P = {new n2 \NT) {new ny :NT)P, ny ^ «2 
{new n:NT)P = P, n^ Jn{P) 
t.M = M 
M.e = M 

{My .M2 ) .M3 = Ml . (M2 .M3 ) 

Pi ^ Pi 



Py=Pi 
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4.3. NETWORK AND LOG PREDICATES 

Several of the computation rules must examine the logs in order to check pre- 
conditions for their successful execution. The predicates that they evaluate are 
given by the rules below. The predicates check if a transaction has successfully 
committed, if a transaction has aborted, if a transaction has received a particular 
message, and if a transaction depends causally on another transaction. Causal 
dependencies are introduced between transactions t\ and ?2 when t 2 receives a 
message from t\. 

C-- — (Log Predicate Extend) 

t{commit} |= t committed (Log Predicate Committed) 
t{abort] 1= t aborted (Log Predicate Aborted) 



^recv ^ t\{receive{out ,F^P)} = t2{send{in ,V)} 

(TVrecv I ^mesg) ^ received 

(Log Predicate Recvd) 

L\=h received = t2{send{in n"** , P ) } 

L\= t 2 "^ t\ 

(Log Predicate Depends) 
This last rule determines if there is a causal dependency from a process in the 
transaction t2 to a process in the transaction t\ . If there is such a dependency, 
then if the transaction t2 aborts, the transaction t\ is also required to abort. We 
extend these log predicates X |= ^ to to network predicates N\= 



{N\ \N2)\=J 

n^JhU) 

{new n : NT)N ^ j 



(Net Predicate Par) 



(Net Predicate New) 



L\= 7 or A 1= 7 

— (Net Predicate Place) 
nP^[L,N]\=y 



4.4. NETWORK NAVIGATION RULES 

The semantics of the ATF Calculus is based on messages that navigate admin- 
istrative domain boundaries and eventually “deposit themselves” in channels at 
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the destination place. This message can then only be read by a process execut- 
ing the receive operation at that place, so message-passing is strictly local. All 
of this is similar to algebras for mobile computation such as the Ambient Cal- 
culus and the Seal Calculus. The following mles allow a message to navigate 
in and out of administrative domains, with the crossing of firewalls mediated 
by capabilities associated with the message: 



N' = t{send{M,V)] 

t{send{inriP^.M,V)} | n'^\L,N] — > n^\L^{N' \ N)] 



(Red In Place) 



N' = t{send{M,V)} 

n^\L,{t{send{out n^\M,V)} \ A)] — > {N' \ rP\L^N]) 

(Red Out Place) 



4.5. COMMUNICATION RULE 

The Red Recv rule allows allows a message to be retrieved from a channel 
by a receiving process. This is the synchronization point in the calculus. To 
a large extent it is the most important reduction rule in the calculus, since it 
establishes a causal relationship between the sending and receiving transaction. 
A log entry is written to stable storage, both to record a change in the state of the 
place, and also to record the causal dependency introduced by synchronization 
in the log: 



^recv ^ [receive{out F, P ) } 
y^mesg = t2{send{in P)} N' = tx {F{V)} 

L^ti aborted L^t2 co mmi tted L' = L; | A^““ 8 ) 

I I at)] — ^ nP\L',{N' \ iV)] 

(Red Recv) 

The side-condition that L^t2 committed reflects that a committed process 
cannot receive any new messages, since it might introduce causal dependencies 
on uncommitted transactions that subsequently aborted. 

5. COMMIT AND ABORT 

In this section we consider the semantics of the commit and abort operations. 
The abort operation writes an entry on the log and rolls back the computation 
of the aborted process. “Rollback” in this respect simply entails restoring 
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messages that were received by this process. 

L t committed L ^ t aborted 

{A^i, . . .,Nk} = {N \ L\=t received A^} 
N'=!Kl{N I (M |■■.| Nk))}t 
n^\L,{N I t{abort})] — >• n^\{L\t {abort}), N'\ 



(Red Abort) 



The metafunction denotes the process of killing any processes in the 

transaction t: 



Xlrf\L,N]\t = 

XlNi I Aalt = 

J(\{new n : NT)N}t = 
Xlt'[P}}t = 



n^\L,N] 

I Kimt) 

{new n : NT) 

t'{P] if 
0 otherwise 



For simplicity in this account, we do not roll back messages sent by an aborted 
process (once they have left the local site). Any process that receives such a 
message will be unable to commit. For local processes, the Red Recv rule 
ensures that such processes ignore messages sent by processes that execute 
within transactions locally to this place (such a message may return after wan- 
dering around the network). However it is unclear how to achieve a scalable 
version of this for processes that may receive messages from an aborted remote 
transaction. 

It remains to give the semantics of the commit operation. The commitability 
predicate plays an important role in defining the preconditions for this operation. 
A transaction t\ is allowed to commit if all transactions tz that it depends on 
causally have committed, or are trying to commit. If the latter case t\ does 
conunit, then t 2 must also commit. The complication with commitment is that 
a collection of transactions may be causally dependent on each other. We do not 
attempt to prevent causal cycles because there is no scalable way to enforce such 
a restriction. Instead several transactions that are in a causal cycle must commit 
simultaneously. The commitability predicate determines that a collection of 
transactions {ti , . . . , are ready to commit. 



Definition 1 (Commitability) The ( possibly mutually dependent) transactions 
ti,...,tk can be committed in the network N, written 
^ 1 = {hi---ih} commitable, if it can be justified by the following inference 
rules: 

bli N {^ 1 ) ■ • • 5 commitable N2\= {ti,-.-,tic} commitable 
(Ni I 7/2) 1 = {^1 ) • • • )^*} commitable 



(Commit Wire) 
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NT ^ Trans TV ^ , . . . , commitable 



(Commit New) 



{new n : NT)N [= , . . . , commitable 

t N \=t committed or (TV li for i = 1,. . . 

TV 1= {ti , . . . , commitable 
{new t : Trans)N ^ , . . . , Tjt} commitable 

(Commit New Trans) 



L ^ ti aborted and L ^ u committed for i = 1 , . . . , ^ 
TV 1= {Ti , . . . , r*:} commitable 
n^\L,N] 1= {Ti, . . ,,tk} commitable 

r{P} 1= {Ti , . . . ,Tyt} commitable 



(Commit Place) 
(Commit Proc) 



0 1= {Ti , . . . , commitable 



(Commit Null) 



tv' 1= {li , . . . , I*} commitable TV' = TV 
TV 1= {li , . . . , commitable 



(Commit Cong) 



Define network contexts and commit contexts by: 



N[] 



= [] I rP^M]] 1 (N I N[]) I (n^wn:TVr)N[] 
= N[Xi] 

I nP‘[AC[Xi,...,X4 
I (TV I C[Xi,...,X„]) 

I {newn:NT)C[Xi,...,X„] 

I (C[Xi,...,X^] I C[X^+i,...,X;„]) 



where, for commit contexts, in the last case 0<k<m, and in the first case m = 1 . 
A commit context is used to describe the simultaneous atomic commitment of k 
transactions. Simultaneous commitment is necessary because of the possibility 
of causal cycles in the causal dependency graph. 



Definition 2 (Global Computation) The global computation relation N\ 
TVa relates networks N\ and TV 2 according to the following rules: 

Ni=N[ N[ — )■ TV 2 TV2 = TV2 
TVi — >■ TV2 



(Red Cong) 
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P\ Pi 

N[f{Pi}] ^ N[t{P2}] 



(Red Prog) 



N = C[M,. . ..,Nk] 1= {/i, . . . commitable 

f Ni = nf[£i,{N'i I ti{commit})] 1 . ■ , . 

[ N'/ = nf[{Li-,ti{commit}),Nl] J 

{new tk : Trans)C[Ni Nk] — > (new tk : Trans)C\N'( , Njl] 

(Red Commit) 



We rely on a protocol such as the distributed two-phase commit protocol 
to actually implement the commit operation [19]. It is well-known that it is 
not possible to devise a non-blocking protocol for atomic commitment in an 
asynchronous system [16, 14]. 

Our intent is to describe and motivate the calculus, and so we eschew detailed 
discussion of its safety properties. The obvious safety property that we can 
check is type safety: 

Lemma 1 Let — ^ denote the reflexive transitive closure of — > . IfT\- 
N net and N -4 N', then T\- N' ntit 



We can verify other safety properties of the calculus by giving a translation 
to a semantics where the effects of aborted transactions are undone. Messages 
originating in such transactions are removed from message channels, and the 
records of the effects of such transactions are erased from logs. This provides 
a verification of the calculus in the sense that any effect obtained from a “run” 
of the network, and remaining after transactions have aborted, could also be 
obtained from a run where no aborted transaction ran in the first place. This is the 
causal consistency property of the calculus: the commit and abort rules ensure 
that any effects remaining after undoing the effects of aborted transactions are 
obtainable from the executions of unaborted transactions. 

A more problematic question is what process equivalences can be defined. 
The complication is that the liveness properties of processes may be quite dif- 
ferent unless one also considers uncommitted effects. However considering 
such effects introduces the possibilities of negative effects (undoing message 
sends due to aborts) and it is not clear how to obtain a fixed point. This remains 
an interesting topic for future work. 



6. ADDING MOBILITY: THE ATFm CALCULUS 

As noted in Sect. 3.1, the ATF Calculus is first-order, in the sense that pro- 
cesses cannot be transmitted as part of the message payload. Allowing processes 
in messages is straightforward, but complicates the meta-theory. Calculi such 
as the 7t-calculus and the ambient calculus avoid higher-order processes by 
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passing “trigger channels” in messages (in the n-calculus) or moving a process 
through the network (in the ambient calculus). In this section we consider how 
a similar approach to passing processes in messages may be incorporated into 
the ATF calculus. We call this extension of the ATF Calculus the ATFm Cal- 
culus. This extension introduces some redundancy, principally with respect to 
the encryption operations. The base calculus has the encryption operations of 
the Spi-calculus [1], while the extension considered here also uses the approach 
to encryption of the ambient calculus [8]. On the other hand, the encoding of 
process transmission here, motivated by a desire to keep values and processes 
separate, is not as natural as the other operations in the base calculus, so we 
treat process transmission as an extension of this base calculus. 

The main addition to the calculus is a message sending operation that in- 
cludes a process in the payload. There are two operations for accessing such a 
message: & forward operation for forwarding the message to another destina- 
tion without accessing the message itself, and an open operation for “liberating” 
the process payload from the message. The latter operation is similar to the 
open primitive in the ambient calculus, but extended to avoid any race condition 
between dissolution and receipt of any communication from that process, and 
also extended to incorporate atomic failure semantics. The extensions to the 
syntax are: 

P€ Process ::= send{M,F) Message Proc Send 

I forward{M,M',Pi,P 2 ) Message Proc Forward 

I open{M,M',Pi,P 2 ) Message Proc Open 

re Type ::= T -)• () 

Although types include process types T -> (), processes are still second- 
class by a syntactic distinction: continuations F are not values V. Process 
types are used in typing the operations for forwarding and opening messages 
containing processes, although process values are not exchanged as part of these 
operations. 

The type rules are best understood by first considering the reduction rules 
for these operations. First, there are two reduction rules that allow messages 
containing processes to navigate the network, similarly to the Red In Place 
and Red Out Place reduction rules in Sect. 4.4. We omit these rules for 
lack of space; they are reasonably obvious. 

The next reduction rule allows a message containing a process to be for- 
warded to a new destination. This destination is identified by a path in and 
out of places, and an eventual channel into which the process should be de- 
posited. The forwarding operation requires a capability for reading the channel 
into which the message has been deposited. It is assumed that the message is 
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encrypted, and the capability constructed by the forwarding operation ensures 
that the message arrives still encrypted at the new destination: 

^forw = {forward{out , M, A , P 2 ) } 

= t2{sendiin n"^^n /^P^F)} 

A^' = ri{Pi I send{M.inn^^,F)} 

L^h aborted committed L' = L; \ 

1 I M)] nP\L',{N' \ W)] 

(Red Forward) 

Finally we have the rule for “dissolving” a message containing a process. The 
message is deposited in a channel, so the opening process must have a capability 
for reading that channel. The message is also assumed to be encrypted, so the 
opening process must have a capability for decrypting the message. We must 
also avoid any potential race condition caused by the fact that dissolving the 
message and communicating with the process so invoked do not constitute an 
atomic action. This is why the message is a continuation, abstracting over a 
capability for a communication channel. The opening process provides this 
capability as part of the opening operation, with the expectation that this is 
a private channel for initiating co mm unication between the liberated process 
and the opening process. Finally the liberated process must execute within 
a transaction, so it executes in the transaction of the process that opened the 
message: 

A^open = {open{out rf^.out Pi , P 2 )} 

A^mesg = t2{send{in rf^.in 
N' = h{F{M) I Pi} 

L^t\ aborted X ^ ?2 committed L' = L\ (A^°p“ | 
nP‘[X,(AT°P®“ I 1 N)] — ^ nP\L',{N' \ A^)] 

(Red Open) 

Note that this form of synchronization with a process, liberated from a mes- 
sage payload, does not obviate the need for the value-passing communication 
channels that are already part of the ATF Calculus. These channels are still 
necessary for communication between the liberated process and the opening 
process. 

There are also timeout rules for the forward and open operations: 

forward{outn'^'^,M,Pi,P2) P 2 (Red FORWARD Timeout) 



open{out .out ,M ,P\,P 2 ) P2 (Red Open Timeout) 
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With these reduction rules, we are in a position to provide the type rules for the 
operators. The process-containing message requires that the process in fact be a 
continuation, parameterized over a capability for a channel for receiving values 
of type T. The capability associated with the message terminates with a key 
for encrypting the message. The forwarding message requires a capability for 
accessing the channel into which the message has been deposited (in encrypted 
form), as well as a capability for a channel to which the message is to be 
forwarded. Both of these capabilities have the same type, since the type system 
does not distinguish input and output capabilities. Finally the open operation 
requires a capability for accessing a channel and descrypting the message. The 
message payload should be a continuation parameterized over a capability for 
a private communication channel, to be supplied by the opening process. 



r h M ; Cap[Packet[Cap[Chan[T]] -A ()]] T h F : Cap[Chan[T]] ^ () 



r\-send{M,F) : () 



(Proc PSend) 



T\- M : Cap[Chan[Packet[Cap[Chan[T]] — > ()]]] 
r\~M' : Cap[Chan[Packet[Cap[Chan[T]] — > ()]]] 

rhFi:() ri-F2:() 

r\-forward{M,M',PuP 2 ) : () 

r h A/ : Cap[Packet[Cap[Chan[T]] ()]] 
r h M' ; Cap[Chan[T]] P F Fi : () P h Fa : () 
r\-open{M,M',Pi,P 2 ) : () 



(Proc Forward) 



(Proc Open) 



7. RELATED WORK AND CONCLUSIONS 

Numerous process algebras have been proposed as the foundations of pro- 
gramming languages for wide-area applications. Most of this work is based on 
mobile computation and mobile code to deal with latency and firewall prob- 
lems [12, 8, 10, 26, 17]. Much of this work has focused on access control 
for mobile computation in networks, as well as tracking the trustworthiness 
of hosts. Although some work has looked at failures [3, 13, 25, 4], this work 
has assumed a fail-stop model of failures that is unrealistic in asynchronous 
distributed systems. 

There is a superficial similarity between parts of the ATF-Calculus and the 
LF-Calculus of Riely and Hennessy [25] . The latter work is an extension of CCS 
with locations and failures, and it is also a two-tier calculus where processes 
execute at specific locations. Operations include an operation for “killing” a 
location, including all processes executing at that location, and operations for 
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testing if a location is live. However these similarities are only superficial, since 
places play the role of locations in our system and transactions are a construct 
for controlling the granularity of causal dependencies. There is no notion in the 
LF-Calculus of committing effects or of using logs to undo effects. The ATF 
Calculus was developed independently of the latter work. 

The Argus distributed programming language [20] incorporated atomic re- 
mote procedure calls based on the use of nested transactions [21, 24]. The 
semantics of nested transactions generalize the original database semantics of 
transactions (for example, correctness is again based on serializability and re- 
coverability [5]). An important difference between nested transactions and the 
model of transactions considered here is that we allow interference between 
transactions, whereas the serializability correctness criterion for nested trans- 
actions requires that sibling transactions be isolated from each other. Since 
parent and child transactions share locks, a distinction is made between leaf 
transactions that access data objects and transactions that spawn other trans- 
actions, so a parent transaction never interferes with a descendant transaction. 
The only causal dependency allowed is the dependency of a child transaction 
on the parent transaction that created it. We provide a more relaxed correct- 
ness criterion, leaving the correctness of concurrency control to the application. 
Haines et al [15] describe a subroutine library in ML that enhances applications 
with transactional semantics, with the semantics of nested transactions. Then- 
library provides undoability and persistence as orthogonal features, however 
they do not give a semantics for these features (while acknowledging that there 
is interaction between the features). 

It is straightforward to add an operation to the ATF Calculus for creating new 
transactions (with child transactions depending causally on parent transactions). 
We intend to investigate this further, in the context of considering more flexible 
ways for creating and combining transactions. 
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REWRITING LOGIC AND MAUDE: 

A WIDE-SPECTRUM SEMANTIC 
FRAMEWORK FOR OBJECT-BASED 
DISTRIBUTED SYSTEMS 



Jose Meseguer 



Abstract Rewriting logic seems very well suited as a semantic framework for open 
object-based distributed systems. Both the distributed states and the 
local concurrent transitions of such systems can be naturally specified by 
rewrite theories in which such local concurrent transitions are described 
by rewrite rules. Maude is a high-performance rewriting logic language 
and system developed at SRI International that supports executable 
specification and programming, and a flexible variety of formal analyses. 

As a wide-spectrum semantic framework, rewriting logic can span 
the gap between high-level properties and architectural designs on the 
one hand, and distributed or mobile system implementations on the 
other. Rewriting logic has been used to give a precise semantics to a 
number of distributed architectural notations and to obtain formal exe- 
cutable specifications from them. Using Maude and its associated tools, 
such executable specifications can then be formally analyzed in a va- 
riety of ways. Furthermore, high-level properties of such specifications 
expressed in nonexecutable formalisms such as temporal and modal log- 
ics can likewise be analyzed and verified. Since under quite reasonable 
assuptions rewriting logic specifications can be directly implemented as 
distributed and mobile systems, it is possible to span the gap from high- 
level designs to implementations without leaving the formal framework. 
This paper introduces rewriting logic and Maude, and surveys the ex- 
perience that, thanks to the efforts of several research teams, has been 
gained so far in applying them to open object-based distributed systems. 



1. INTRODUCTION 

Rewriting logic [55] seems very well suited as a semantic framework 
for open object-based distributed systems. Both the distributed states 
and the local concurrent transitions of such systems can be naturally 
specified by rewrite theories in which such local concurrent transitions 
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are described by rewrite rules. Specifically, the distributed state can be 
axiomatized as an algebraic data type by an equational theory 
and each rewrite rule t — > t' is interpreted as a local transition in the 
distributed state of the system. That is, t and describe patterns for 
fragments of the distributed state of a system, and the rule specifies how 
a local concurrent transition can take place in such a system, changing 
the local state fragment from the pattern t to the pattern t'. 

Rewriting logic then provides a simple inference system in which one 
can derive all the possible finitary concurrent transitions of the sys- 
tem so axiomatized. That is, concurrent computations exactly corre- 
spond to deductions in the logic. Furthermore, the initial model Tn 
of a rewrite theory TZ is built out of the proof theory, so that its ele- 
ments are equivalence classes of proofs^ which are understood as abstract^ 
truly- concurrent computations. Specifically, for rewrite theories specify- 
ing object-based distributed systems, Carolyn Talcott and I have shown 
that, under very reasonable assumptions, each equivalence class of proofs 
is in bijective correspondence with a partial order of events^ in which the 
basic events are precisely the local concurrent rewrites [57]. 

An important advantage of rewriting logic specifications is that they 
are executable. Therefore, they provide an executable formal model 
of the specified system, that can be simulated, and can be analyzed 
and reasoned about using a variety of model checking and proof tech- 
niques. There are in fact three language implementations of rewriting 
logic, namely, ELAN [42, 7, 6], CafeOBJ [35], and Maude [16, 12]. In 
particular, Maude is a high-performance rewriting logic language and 
system developed at SRI International that supports executable specifi- 
cation and programming of distributed object-based systems. Further- 
more, Maude is refiective, and this can be used to formally analyze the 
behavior of Maude specifications by fiexible model checking strategies 
defined within the language. 

Executability can be exploited not just for formal specification, sym- 
bolic simulation, and formal analysis purposes: with appropriate com- 
pilation techniques rewrite rules can in fact be the code of parallel, dis- 
tributed, and mobile systems that are then much easier to develop, de- 
bug, and analyze than similar systems built with conventional code. This 
possibility has been demonstrated by the Simple Maude language and 
compilation techniques in the context of parallel computing [47, 48, 49]. 
At present, Francisco Duran, Steven Eker, Patrick Lincoln and I are 
working on the design and implementation of Mobile Maude [29], which 
will demonstrate the same possibility in the context of mobile computing 
and internet programming. 
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As a wide-spectrum semantic framework rewriting logic seems well 
suited to span the gap between high-level properties and architectural 
designs on the one hand, and distributed or mobile system implemen- 
tations on the other. Rewriting logic has been used to give a precise 
semantics to a number of distributed architectural notations and con- 
cepts, and to obtain partially- or fully-defined formal executable specifi- 
cations from such notations. Using Maude and its associated tools, such 
executable specifications can then be analyzed in a variety of ways, in- 
cluding symbolic simulation and debugging, and fiexible forms of model 
checking analysis. Furthermore, using model checkig analysis and formal 
proofs, high-level properties of such specifications expressed in nonexe- 
cutable formalisms such as temporal and modal logics can likewise be 
analyzed and verified. Since, as already mentioned, rewriting logic spec- 
ifications can under quite reasonable assuptions be directly implemented 
with competitive performance as distributed and mobile systems, it is 
possible to span the gap from high-level designs to distributed imple- 
mentations without leaving the formal framework. 

As a research program, all this is quite ambitious, and should be con- 
sidered as work in progress^ that has not yet been fully realized. How- 
ever, thanks to the efforts of very gifted researchers in several research 
teams, a substantial body of encouraging experience already exists. The 
goal of this paper is to introduce rewriting logic and Maude, and to sur- 
vey the experience gained so far in applying them to open object-based 
distributed systems. Section 2 explains how concurrent object systems 
are axiomatized in rewriting logic. Section 3 introduces the basic con- 
cepts of the Maude language. Section 4 explains the range of formal 
methods that can be used to analyze and reason about rewriting logic 
specifcations, the formal tools available, and the specification logics in 
which properties can be stated. Section 5 discusses a number of applica- 
tions of rewriting logic and Maude to object-based distributed systems 
developed so far by different researchers. The paper ends with some 
concluding remarks 

2. CONCURRENT OBJECTS IN 
REWRITING LOGIC 

Using an informal style of presentation, I explain how concurrent 
object systems are axiomatized in rewriting logic, and how concurrent 
object-based computations correspond to proofs in the logic and yield 
an algebraic model of “true concurrency” . In general, a rewrite theory 
is a triple IZ = (S,FJ, i?), with an equational specification with 

signature of operations E and a set of equational axioms E; and with 
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R a collection of labelled rewrite rules. The equational specification de- 
scribes the static structure of the system’s state space as an algebraic 
data type. The dynamics of the system are described by the rules in 
R that specify local concurrent transitions that can occur in the system 
axiomatized by and that can be applied modulo the equations E. 

Let me explain how the state space of a concurrent object system 
can be axiomatized as the initial algebra of an equational theory (S, E). 
That is, I explain the key state-building operations in E and the equa- 
tions E that they satisfy. The concurrent state of an object-oriented sys- 
tem, often called a configuration^ has typically the structure of a multiset 
made up of objects and messages. Therefore, we can view configurations 
as built up by a binary multiset union operator which we can represent 

with empty syntax (i.e. juxtaposition) as : Conf x Conf — y Conf. 

(Following the conventions of mix-fix notation, _s are used to indicate 
argument positions.) The operator is declared to satisfy the struc- 

tural laws of associativity and commutativity and to have identity 0. 
Objects and messages are singleton multiset configurations, and belong 
to subsorts Object, Msg < Conf, so that more complex configurations 
are generated out of them by multiset union. 

An object in a given state is represented as a term 



{O : C \ ai \ Vi, . . . ,an : Vn) 



where O is the object’s name or identifier, C is its class, the a^’s are 
the names of the object’s attribute identifiers^ and the u^’s are the cor- 
responding values. The set of all the attribute-value pairs of an object 
state is formed by repeated application of the binary union operator 
_ , _ which also obeys structural laws of associativity, commutativity, 
and identity; i.e., the order of the attribute- value pairs of an object is 
immaterial. This finishes the description of some of the sorts, operators, 
and equations in the theory (E, £?) axiomatizing the states of a concur- 
rent object system. Particular systems will have additional operations 
and equations, specifying, for example, the data operations on attribute 
values. But the top level structure of the concurrent object system is 
typically given by the multiset union operator. 

The associativity and commutativity of a configuration’s multiset 
structure make it very fiuid. We can think of it as “soup” in which 
objects and messages fioat, so that any objects and messages can at 
any time come together and participate in a concurrent transition corre- 
sponding to a communication event of some kind. In general, the rewrite 
rules in R describing the dynamics of an object-oriented system can have 
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the form 

t(x) : Ml . . . Mfi {0\ ‘ F\ \ attsi ) . . . (Om ; -Fm | dttSfyi) 

{Qi : Di I atts'l ) . . . (Qp : Dp \ attSp) 

M' . . . M' 
if C 

where r is the label, x is a list of the variables occurring in the rule, the 
Ms are message expressions, ii, . . . , are different numbers among the 
original 1, . . . ,m, and C is the rule’s condition. That is, a number of 
objects and messages can come together and participate in a transition 
in which some new objects may be created, others may be destroyed, 
and others can change their state, and where some new messages may 
be created. If two or more objects appear in the lefthand side, we call the 
rule synchronous^ because it forces those objects to jointly participate 
in the transition. If there is only one object in the lefthand side, we call 
the rule asynchronous. 

For example, we can consider three classes of objects. Buffer, Sender, 
and Receiver. The buffer stores a list of numbers in its q attribute. 
Lists of numbers are built using an associative list concatenation opera- 
tor, _ . _ with identity nil, and numbers are regarded as lists of length 
one. The name of the object reading from the buffer is stored in its 
reader attribute. The sender and receiver objects store a number in 
a cell attribute that can also be empty (mt) and have also a counter 
(cnt) attribute. The sender stores also the name of the receiver in an 
additional attribute. The counter attribute is used to ensure that mes- 
sages are received by the receiver in the same order they are sent by 
the sender even though communication between the two parties is asyn- 
chronous. Each time the sender gets a new message from the buffer, it 
increments its counter. It uses the current value of the counter to tag 
the message sent to the receiver. The receiver only accepts a message 
whose tag is its current counter. It then increments its counter indicat- 
ing that it is ready for the next message. Three typical rewrite rules for 
objects in these classes (where E and N range over natural numbers, L 
over lists of numbers, L . E is a list with last element E, and (to Z : E 
from (Y,N)) is a message) are 

read(X,Y,L,E,N) : < X : Buffer 1 q: L . E, reader: Y > 

< Y : Sender I cell: mt, cnt: N > 

=> < X : Buffer I q: L, reader: Y > 

< Y : Sender I cell: E, cnt: N + 1 > 
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send(Y,Z,E,N) : < Y : Sender 1 cell: E, cnt: N, receiver: Z > 

=> < Y : Sender I cell: mt, cnt: N > (to Z : E from (Y,N)) 

receive (Z,Y,E,N) : < Z : Receiver I cell: mt, cnt: N > 

(to Z : E from (Y,N)) 

=> < Z : Receiver I cell: E, cnt: N + 1 > 

where the read rule is synchronous and the send and receive rules asyn- 
chronous. These rules are applied modulo the associativity and commu- 
tativity of the multiset union operator, and therefore allow both object 
synchronization and message sending and receiving events anywhere in 
the configuration, regardless of the position of the objects and messages. 
We can then consider the rewrite theory TZ = (S, R) axiomatizing the 
object system with these three object classes, and with R the three rules 
above (and perhaps other rules, such as one for the receiver to write its 
contents into another buffer object, that I omit). 

Rewriting logic then gives an inference system to deduce, for a system 
axiomatized by a rewrite theory which are all the finitary concur- 
rent computations possible in such a system. Such computations are 
identified with proofs of the general form a : t — > t' in the logic. In 
what follows, to simplify the exposition, I specialize the general infer- 
ence system of [55] to the case of object systems. Idle, or “identity” 
computations, in which nothing changes in a state are denoted by t 
itself, and elementary rewrites corresponding to the application of a sin- 
gle rule are denoted by the appropriate substitution instance of the rule 
label; for example, send(b,c,3, 1) is the rewrite in which sender object 
b sends to c the value 3 with counter 1. More complex computations 
are then built up by parallel and sequential composition of elementary 
proofs, according to the following inference system, that specifies both 
the inferences and the new proof terms associated to proofs a and (3. 




For example, a buflFer object a, and sender and receiver objects b and c 
can be involved in a concurrent computation in which b reads a value 
from a and sends it to c, and then, simultaneously, c receives it and b 
reads a second value from a. Suppose that we begin with the following 
initial configuration Cq 



< 


a 


Buffer 1 


q: 7 . 


9, 


reader: b > 




< 


c 


Receiver 


1 cell 


: mt 


, cnt: 1 > 




< 


b 


Sender I 


cell: 


mt , 


cnt: 0, receiver : 


: c > 
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Then, the above concurrent computation can be described by the proof 
term a, built up by repeated application of congruence and transitivity 

(read(a,b,7,9,0) < c : Receiver I cell: mt, cnt: 1 >) ; 

(send(b,c,9,l) < c : Receiver I cell: mt, cnt: 1 > 

< a : Buffer I q: 7, reader: b >) ; 

(read (a, b, nil, 7,1) receive (c,b, 9, 1)) 

and has as its final configuration C\ 

< a : Buffer I q: nil, reader: b > 

< b : Sender I cell: 7, cnt: 2, receiver : c > 

< c : Receiver I cell: 9, cnt: 2 > 

This is fine, but when do two different proofs describe the same con- 
current computation? This typical “true concurrency” question is posed 
by approaches in which a more abstract description of concurrent com- 
putations is sought, and models characterizing such computations are 
built. For example, in our computation a we could replace the last step, 
namely (read(a,b,nii,7,i) receive(c,b,9, 1) ) , by either of two different 
“interleaving” proof terms equivalent to it: one in which the receive 
happens after the read, and another in which they happen in opposite 
order. 

Rewriting logic is in this sense a “true concurrency” approach. The 
abstract model giving a semantics to the concurrent computations of a 
system axiomatized by a rewrite theory TZ = (S, -B, i?) is denoted Tn 
and is a quotient of the algebra of proof terms modulo some simple 
equations that express basic equivalences between proofs. The details of 
this algebraic construction for an arbitrary rewrite theory can be found 
in [55]. In [57] Carolyn Talcott and I have given a detailed construction 
7^ specializing to the case of object-oriented systems the Tn model. 
We can give the flavor of these proof equivalences by pointing out that, 
firstly, all the equations E m TZ are also applied to proof terms (in 
particular, parallel composition of proofs in object systems is associative 
and commutative and has identity 0, because multiset union enjoys those 
axioms) and in addition parallel and sequential composition obey, among 
others, the following three equations that are sufficient for proving that 
our proof term a above is equivalent to the two proof terms in which 
the last parallel step has been replaced by interleavings. 

1 Associativity. (a; ^); 7 = a; (/?; 7). 

2 Identities. For each a : t — > t', a;t' = a and t; a = a. 

3 Functoriality. (0:1; A)(<^2; /?2) = (o^i <^2); (A ^ 2 )- 
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By identifying proof terms using equations such as these, the model 
7^ characterizes abstract concurrent computations in an object-oriented 
system as equivalence classes [a] of proof terms a. This algebraic model 
is constructed using initiality (see [57] for the details) and enjoys many 
of the good properties of algebraic constructions, including parallel and 
sequential composition operations. Furthemore, Carolyn Talcott and I 
have proved that, under reasonable assumptions about the rewrite theory 
TZj it is isomorphic to a very natural and intuitive partial order of events 
model that is fully general, in the sense of allowing both synchronous 
and asynchronous computations. In addition, the models 7^ and E'ji 
have a straightforward extension to models of infinite computations 
and £^ that are again isomorphic. In fact, for rewrite theories TZ whose 
rules are all asynchronous and obey the actor locality laws (cf. [67]), 
specializes to the well-known partial order of events model of Hewitt and 
Baker for Actor systems [3, 20]. 

Co Co 




Figure 1 Equivalence between proof and event partial order descriptions of a con- 
current object-oriented computation. 

In the isomorphism 7^ = £^ 7 ^, an equivalence class of proof terms is 
mapped to a partial order of events in which the individual events are 
atomic rewrites. Without giving the formal details, that can be found 
in [57], Figure 1 illustrates this isomorphism by showing the partial 
order of events isomporphic to the equivalence class [a] of proof terms 
for the proof term a in our running example. In 7^ the equivalence 
class of proofs [a] labels an arrow between the beginning and ending 
configurations Co and Ci. In S'jz the same arrow is instead labeled by 
the corresponding partial order of events. Note that the events are the 
elementary rewrites corresponding to applying each one of the rules, and 
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the order between them is the causality relation between such events. 
Thus, the first send and the receive events are causally connected, but 
the second read and the receive are unrelated in the causal partial 
order. 



3. MAUDE 

Maude [12, 13] is a language and system developed at SRI Interna- 
tional whose modules are theories in rewriting logic. The most general 
Maude modules are called system modules. They have the syntax mod 
TZ endm with TZ the rewrite theory in question, expressed with a syntax 
quite close to the corresponding mathematical notation^. The equa- 
tions E in the equational theory underlying the rewrite theory 

TZ = (S,£J, i?) are presented as a union E = E' U with A a set 
of equational axioms introduced as attributes of certain operators in 
the signature S — for example, an operator -f can be declared associa- 
tive and commutative by keywords assoc and comm — and where E' is 
a set of equations that are assumed to be Church- Rosser and terminat- 
ing modulo the axioms A. Furthermore TZ is assumed to be (weakly) 
coherent [71], which intuitively means that the equations E^ and the 
rules R “commute with each other” modulo A in an appropriate sense. 
Maude supports rewriting modulo different combinations of such equa- 
tional attributes A: operators can be declared with any combination 
of associative, commutative, and with left, right, or two-sided identity 
attributes. 

Since we can view an equational theory cis a rewrite theory whose set 
R of rules is empty, Maude contains a sublanguage of functional mod- 
ules of the form f mod (S, E) endf m, where, as before, E = E^ U A, with 
E' Church-Rosser and terminating modulo A. The equational logic of 
functional modules and of the equational part of system modules is mem- 
bership equational logic [56], an expressive logic whose atomic formulas 
are equations t = t' and membership predicates t : s with s a sort. Mem- 
bership equational logic is quite expressive. It supports sorts, subsorts, 
operator overloading, and equational partiality. But this expressiveness 
is achieved while being efficiently executable by rewriting and having 
suitable techniques for completion and for equational theorem proving 
[ 8 ], 

Maude has a third class of modules, namely, object-oriented mod- 
ules^ that specify concurrent object-oriented systems and have syntax 



^See [12] for a detailed description of Maude’s syntax, which is quite similar to that of OBJ3 
[37]. 
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omod TZ endom, with TZ a sugared form for a rewrite theory. That is, 
object-oriented modules are internally translated into ordinary system 
modules, but Maude provides a more convenient syntax for them, sup- 
porting concepts such as objects, messages, object classes, and multiple 
class inheritance. Some of the syntax of object-oriented modules has 
been illustrated in Section 2. The two key points to bear in mind about 
object-oriented modules are: that rewriting takes place modulo the ax- 
ioms of associativity, commutativity, and identity axioms of the multiset 

union operator for configurations : Conf x Conf — > Conf, and 

that rewrite rules can be either synchronous or asynchoronous and have 
the general form explained in Section 2. 

Modules in Maude have an initial semantics. Therefore, a system 
module mod TZ endm specifies the initial model Tn of the rewrite theory 
TZ. Similarly, a functional module fmod (S, E) endfm specifies the initial 
algebra Ty,^e of the equational theory (S, J5). 

In addition, like in OBJ3, Maude supports a module algebra with pa- 
rameterized modules, parameter theories (with ‘‘loose” semantics) views 
(that is, theory interpretations) and module expressions. In Maude, this 
module algebra, called Full Maude, is defined inside the language by re- 
fiection, and is easily extensible with new module composition operations 
[30, 28]. Such a module algebra is one important concrete application 
of the general metaprogramming capabilities made possible by Maude’s 
support of refiection through the META-LEVEL module. Refiection, as 
well as the refiective capacity for defining internal strategy languages 
that can guide the execution of rewrite theories by means of rewrite 
rules at the metalevel are explained below. 

Even though the Maude system is an interpreter, its use of advanced 
semicompilation techniques that compile each rewrite rule into match- 
ing and replacement automata [33] make it a high-performance system 
that can reach up to 1.66 million rewrites per second in the free theory 
case {A = 0) and from 130,000 to one million rewrites per second in 
the associative-commutative case on a 500 MHz Alpha for some applica- 
tions. In addition, a Maude compiler currently under development can 
reach up 13 million rewrites per second on the same hardware for some 
applications. 

This means that Maude can be used effectively not only for executable 
specification purposes, but also for declarative programming. Further- 
more, as already mentioned, there is a substantial body of encouraging 
experience on parallel compilation for the Simple Maude sublanguage 
[47, 48, 49], and the design of the Mobile Maude language extension is 
currently under development [29] (see Section 5.3). 
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Executables for the Maude interpreter, a language manual, a tutorial, 
examples and case studies, and relevant papers can be found in http : 
//maude . csl . sri . com. 

Reflection and Strategies 

Intuitively, a logic is reflective if it can represent its metalevel at the 
object level in a sound and coherent way. More precisely, Manuel Clavel 
and I have shown that rewriting logic logic is reflective [17, 11, 19] in the 
sense that there is a flnitely presented rewrite theory U that is universal 
in the sense that for any flnitely presented rewrite theory TZ (including 
U itself) we have the following equivalence 

TZ\~ t — y 44*- lA h" (7?^, t) — y (7^5 ^0? 

where TZ and t are terms representing TZ and t as data elements of U. 
Since U is representable in itself, we can achieve a “reflective tower” with 
an arbitrary number of levels of reflection, since we have 

TZht^t' ^ (^~t) ^ u\- (i7, {TZ,i)) {U, {lz,f )) . . . 

Reflection is a very powerful property. It is systematically exploited 
in the Maude rewriting logic language implementation [12], that pro- 
vides key features of the universal theory W in a built-in module called 
META-LEVEL. In particular, META-LEVEL has sorts Term and Module, so 
that the representations t and 7?. of a term t and a module TZ have 
sorts Term and Module, respectively. META-LEVEL has also functions 
meta-reduce(7?., i) and meta-apply(7?., 7, /, a, n) which return, re- 
spectively, the representation of the reduced form of a term t using the 
equations in a module TZ, and the (representation of the) result of ap- 
plying a rule labeled I in the module 7?. to a term t at the top with 
the (n + l)th match consistent with the partial substitution cr. As the 
universal theory U that it implements in a built-in fashion, META-LEVEL 
can also support a reflective tower with an arbitrary number of levels of 
reflection. 

Reflection can be exploited to deflne internal rewriting strategies [17, 
18, 11], that is, strategies to guide the rewriting process whose semantics 
can be deflned inside the logic by rewrite rules at the metalevel. In fact, 
there is great freedom for deflning many different strategy languages in- 
side Maude. This can be done in a completely user-definable way, so that 
users are not limited by a fixed and closed strategy language. The idea 
is to use the operations meta-reduce and meta-apply as basic strategy 
expressions, and then to extend the module META-LEVEL by additional 
strategy expressions and corresponding semantic rules. A number of 
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strategy languages that have been defined following this methodology 
can be found in [11, 13]. 

4. FORMAL METHODOLOGY, TOOLS, AND 
SPECIFICATION LOGICS 

In this section I explain how a fiexible range of formal methods can 
be applied to rewriting logic specifications (4.1) the existing formal tools 
supporting these methods (4.2) and the different specification logics that 
can be used to state formal properties (4.3). 

4.1. FORMAL METHODOLOGY 

The fact that rewrting logic specifications are executable allows us to 
have a fiexible range of increasingly stronger formal methods, to which 
a system specification can be subjected. Only after less costly and 
“lighter” methods have been used, leading to a better understanding 
and to important improvements and corrections of the original specifi- 
cation, is it meaningful and worthwhile to invest effort on “heavier” and 
costlier methods. Maude and its theorem proving tools [14, 63] (more on 
this below) can be used to support the following, increasingly stronger 
methods: 

1 Formal specification. This process results in a first formal model 
of the system, in which many ambiguities and hidden assumptions 
present in an informal specification are clarified. A rewriting logic 
specification provides a formal model in exactly this sense. 

2 Execution of the specification. Executable rewriting logic specifica- 
tions can be used directly for simulation and debugging purposes, 
leading to increasingly better designs. 

3 Model- checking analysis. Errors in highly distributed and nonde- 
terministic systems not revealed by a particular execution can be 
found by a model-checking analysis that considers all behaviors of 
a system from an initial state, up to some level or condition. 

4 Narrowing analysis. By using symbolic expressions with logical 
variables, one can carry out a symbolic model-checking analysis in 
which all behaviors not only from a single initial state, but also 
from the possibly infinite set of states described by a symbolic 
expression are analyzed. 

5 Formal Proof. For highly critical properties it is also possible to 
carry out a formal proof of correctness, which can be assisted by 
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formal tools such as those described in Section 4.2 below. Such 
properties can be expressed in rewriting logic itself, or in an ade- 
quate modal or temporal logic as explained in Section 4.3 

4.2. FORMAL TOOLS 

The above methodology is supported by the formal tools described in 
what follows. First of all, Maude itself is a very versatile formal tool 
supporting methods 1-2 through its default interpreter, and method 
3 through reflective rewriting strategies that can analyze the diflFerent 
concurrent computations from a given initial state checking for desired 
properties. In a future release of Maude we plan to support uniflcation in 
a built-in way, which will make it easy to support method’s 4 narrowing 
analysis. 

In addition to the formal methods directly supported by Maude, one 
can use Maude as a formal meta-tool [15] to build other formal tools sup- 
porting other kinds of analysis and proof. As explained in [14, 15, 54], 
reflection and the flexible uses of rewriting logic as a logical framework 
[50] are the key features making it easy to develop such formal tools 
and their user interfaces. Interfaces can be built using the general meta- 
parsing and meta-pretty printing functions of the META-LEVEL module, 
and the LOOP-MODE module [12], that provides a general read-eval-print 
loop that can be customized with appropriate rewrite rules to deflne the 
interaction with the user for each tool. Our experience suggest that it 
is much easier to build and maintain formal tools this way than with 
conventional implementation techniques. Also, because of the high per- 
formance of the Maude engine, the tools generated this way often have 
quite reasonable performance. Of course, special-purpose algorithms or 
oflF-the-shelf tools can also be used as components for performance or 
convenience reasons, since this is not excluded by Maude’s meta-tool 
building capabilities. 

The papers [15, 63] give detailed accounts of different formal tools, 
including theorem proving tool, execution and analysis environments for 
different formalisms, a module algebra, and logic traislators, that have 
been deflned in Maude by different authors using the above reflective 
methodology. Some tools are more domain-speciflc, or support formal 
analysis and reasoning in other formalisms; I discuss a few of these in 
Section 5. Maude-specific tools, applicable to large classes of Maude 
specifications, or extensions of such specifications, include the following: 

An Inductive Theorem Prover. Using the reflective features found 
in Maude, we have built an inductive theorem prover for equa- 
tional logic specifications [14] that can be used to prove indue- 
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tive properties of both CafeOBJ specifications [35] and of func- 
tional modules in Maude. As already mentioned, this tool can be 
extended with reflective reasoning principles to reason about the 
meta-logical properties of a logic represented in rewriting logic or, 
more generally, to prove metalevel properties [4]. 



A Church-Rosser Checker. We have additionally built a Church- 
Rosser checker tool [14] that analyzes equational specifications to 
check whether they satisfy the Church-Rosser property. This tool 
can be used to analyze order-sorted [36] equational specifications 
in CafeOBJ and in Maude. The tool outputs a collection of proof 
obligations that can be used to either modify the specification or 
to prove them. Extensions of this tool to perform equational com- 
pletion and to check coherence of rewrite theories are currently 
under development. 

Full Maude. Maude has been extended with special syntax for object- 
oriented specifications, and with a rich module algebra of parame- 
terized modules and module composition in the Clear/ OBJ style 
[9, 37] giving rise to the Full Maude language. All of Full Maude 
has been formally specified in Maude using reflection [30, 28]. This 
formal specification — about 7,000 lines — is in fact its implementa- 
tion, which is part of the Maude distribution. Our experience in 
this regard is very encouraging in several respects. Firstly, because 
of how quickly it was possible to develop Full Maude. Secondly, 
because of how easy it will be to maintain it, modify it, and extend 
it with new features and new module operations. Thirdly, because 
of the competitive performance with which it can carry out com- 
plex module composition and module transformation operations, 
that makes the interaction with Full Maude quite reasonable. 



Real-Time Maude. Based on a notion of real-time rewrite theory that 
can naturally represent many existing models of real-time and hy- 
brid systems, and that has a straightforward translation into an 
ordinary rewrite theory [62], Peter Olveczky and I are developing 
an execution and analysis environment for specifications of real- 
time and hybrid systems called Real-Time Maude [63]. This tool 
translates real-time rewrite theories into Maude modules and can 
execute and analyze such theories by means of a library of strate- 
gies that can be easily extended by the user to perform other kinds 
of formal analysis. 
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4.3. SPECIFICATION LOGICS 

Rewriting logic is primarily a logic of change — in which the deduc- 
tion directly corresponds to the change — as opposed to a logic to talk 
about change in a more indirect and global manner such as the differ- 
ent variants of modal and temporal logic. Such logics regard a system 
as a mathematical model — typically some kind of Kripke structure — 
about which they then make assertions about its global properties such 
as safety or liveness properties. Both levels of description and analysis 
are useful in their own right; in fact, they complement each other: one 
can use both logics in combination to prove system properties. 

Of course, the first issue that must be addressed is the semantic in- 
tegration between rewriting logic and the modal or temporal logic of 
choice. Usually, such an integration is straightforward, because both 
logics are talking about essentially the same mathematical model. In 
fact, the initial model 7^ of a rewrite theory 7?. is a category with alge- 
braic structure, where the objects correspond to system states, and the 
arrows correspond to concurrent system transitions. Therefore, 7^ can 
be regarded as a Kripke structure whose transitions are labeled by the 
arrows of the category. A variety of different modal or temporal logics 
can then be chosen to make assertions about such a Kripke structure, 
or about a closely-related structure obtained from it, such as, for exam- 
ple, the extension 7^ of In to infinite computations. In fact, some of 
these logics can be interpreted within first-order rewriting logic^ and we 
can use this first-order logic directly to express relevant properties some- 
times not expressible in a given modal or temporal logic. For example, 
the confluence of a rewrite theory can be expressed by the first-order 
formula 



V(a:, y, z).{x y Ax ^ z) (3u.(y v A z v)). 

The point is that, when we consider arbitrary first-order formulas — and 
not just universally quantified conditional or unconditional rewrite rules, 
which are the axioms in rewrite theories — rewriting logic itself becomes 
another candidate for a nonexecutable specification logic. 

The investigation of suitable specification logics having a good inte- 
gration with rewriting logic is a current area of research. In the choice 
of such a specification logic there are different tradeoffs between, for ex- 
ample, generality, expressiveness, and amenability to different deductive 
and/or model checking techniques. The most general proposal advanced 
so far is the one by J. Fiadeiro et al. in [34], where a modal logic for 
reasoning about general rewrite theories is presented. But since object- 
oriented systems constitute a particularly wide and important applica- 
tion area, modal or temporal logics that provide explicit support for 
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object systems and can reason about their rewriting logic specifications 
are clearly of interest. Two candidate formalisms of this kind have been 
proposed. One is a version of the modal /i-calculus proposed by Ulrike 
Lechner [46, 44, 45] for reasoning about object-oriented Maude specifi- 
cations. Another is Grit Denker’s object-oriented distributed temporal 
logic [21], that extends the distributed object temporal logics of H.-D. 
Ehrich and G. Denker [32, 22, 31]. Another direction being explored 
is real-time formalisms: Peter Olveczky and I are currently investigat- 
ing a variant of linear time temporal logic suitable for reasoning about 
rewriting logic specifications of real-time systems. 

One attractive prospect is the use of Maude’s reflective features to 
build tools mechanizing the desired modal or temporal logic deduction 
and/or model checking, and to integrate such tools with the underlying 
rewriting logic and equational logic formal tools described in Section 4.2. 

5. DISTRIBUTED OBJECT-BASED 
APPLICATIONS 

I discuss work in three broad classes of applications of rewriting logic 
and Maude to distributed object-based systems: (i) distributed architec- 
tures and open components; (ii) networks and communication protocols; 
and (iii) agent and mobile languages. 

5.1. DISTRIBUTED ARCHITECTURES AND 
OPEN COMPONENTS 

It is very important to detect errors and inconsistencies as early as 
possible in the software design cycle. For this reason, formal approaches 
that can increase the analytic power of architectural notations such as 
architectural description languages (ADLs) and object-oriented design 
formalisms such as UML are very valuable. A related concern is the 
formal specification and analysis of distributed component architectures, 
Maude has been used by several authors in these areas to allow formal 
analysis of designs in early design stages, and, in some cases, to support 
code generation from the associated executable specifications. 



■ As part of a project to represent the Wright architecture descrip- 
tion language [1] in Maude, U. Nodelman and C. Talcott have 
developed a representation of CSP in Maude. This is compatible 
with existing tools for analyzing CSP specifications, complements 
them by providing a rich execution environment and the ability 
to analyze non-finite state specifications, and provides a means of 
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combining CSP specifications with other notations for specifying 
concurrent systems. 

In [12] (Appendix E) F. Duran, C. Talcott and I present a sub- 
stantial case study showing how Maude can be used to execute 
very high level software designs, namely architectural descriptions. 
We focus on a difficult case, namely, heterogeneous architectures, 
which is illustrated by a command and control example that in- 
cludes dataflow, message passing, and implicit invocation sub- 
architectures. Using Maude, each of the different subarchitectures 
can not only be executed, but they can also be interoperated in 
the execution of the resulting overall system. 

M. Wirsing and A. Knapp [73] have stressed the practical impor- 
tance of combining object-oriented design notation with formal 
executable specifications. Their proposal is to annotate diagrams 
in an existing and widely-used object-oriented notation and then 
derive formal executable rewriting logic specifications written in 
an extension of Maude. The specifications can then be used to 
execute and formally analyze the designs, and even to generate 
code in a conventional language such as Java. These ideas are 
further developed and implemented in Knapp’s upcoming Ph.D. 
thesis [43]. 

A related proposal is the GILO-2 scenario-based object-oriented 
design notation proposed by S. Nakajima and K. Futatsugi [60]. 
In GILO-2, scenario-based object-oriented diagrams are system- 
atically transformed into rewriting logic formal specifications in 
CafeOBJ. In fact, rewriting logic provides a formal operational se- 
mantics for GILO-2 designs, and allows their execution and formal 
analysis. 

C. Talcott [68, 66, 69] has given a rewriting logic semantics for actor 
systems that are axiomatized by actor theories. She then extends 
actor systems by an algebra of components^ where a component 
is formalized as a distributed subsystem that can include actors, 
messages, and other (sub-)components and that is encapsulated 
by a precisely defined interface that mediates its interactions with 
an open environment. Furthermore, she has developed methods 
to reason formally about such open component systems, including 
techniques to prove behavioral equivalence between such sy terns. 

G. Denker, C. Talcott and I [24] have given an executable speci- 
fication of a general middleware architecture for composable dis- 
tributed communication services such as fault- tolerance, security. 
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and so on, that can be composed and can be dynamically added 
to selected subsets of a distributed communications system. 

■ E. Najm and J.-B. Stefani [58] have used rewriting logic to give a 
formal semantics to the operational subset of the Reference Model 
for Open Distributed Processing (RM-ODP) [40]. RM-ODP speci- 
fies a language-independent computational model underlying many 
of the distributed computational models that have been recently 
proposed, including those adopted for CORBA, the Network Ob- 
ject system, and the Java RMI system. 

■ S. Nakajima [59] shows how the calculus of mobile ambients of 
Cardelli and Gordon [10] can be naturally expressed in rewrit- 
ing logic, and then uses rewriting logic specifications in CafeOBJ 
to formally specify the architecture of WEB-NMS, a Java/ORB 
implementation of a network management system with four archi- 
tectural components. 

5.2. NETWORKS AND COMMUNICATION 
PROTOCOLS 

The paper [26] surveys some of the advances made using Maude to 
specify and analyze communication protocols, including cryptographic 
protocols, and, more generally, network software such as active network 
programming languages, active network algorithms, network manage- 
ment systems, and so on. These advances can be summarized as follows: 

■ The paper [27] reports on joint work by researchers at Stanford 
and SRI with the group led by J.J. Garcia-Luna at the Computer 
Communications Research Group at University of California Santa 
Cruz in which we used Maude very early in the design of a new 
reliable broadcast protocol for Active Networks. In this work, we 
have developed precise executable specifications of the new pro- 
tocol and, by analyzing it through execution and model-checking 
techniques, we have found many deadlocks and inconsistencies, 
and have clarified incomplete or unspecified assumptions about its 
behavior. 

■ Maude has also been applied to the specification and analysis 
of cryptographic protocols [23], showing how Maude’s refiective 
model-checking techniques can be used to discover attacks. 

■ The positive experience with security protocols has led to the adop- 
tion of Maude by J. Millen and G. Denker at SRI as the basis for 
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giving a formal semantics to their new secure protocol specifica- 
tion language CAPSL and as the meta-tool used to endow CAPSL 
with an execution and formal analysis environment [25]. 

■ The paper [72] reports joint work with Y. Wang and C. Gunter at 
the University of Pennsylvania in using Maude to formally specify 
and analyze a PLAN [38] active network algorithm. 

■ In collaboration with M. Keaton and S. Zabele at TASC and S. 
Bhattacharyya at Sprint, P. Olvecky, C. Talcott and I have spec- 
ified and formally analyzed the AER/NCA [41] suite of sophisti- 
cated active network protocol components for reliable multicast. 
This is perhaps the most complex suite of protocols we have stud- 
ied so far, because of its time-sentitive behavior and the need to 
analyze both correctness and performace. The Real-Time Maude 
tool (see Section 4.2) has allowed us to find important errors and 
inconsistencies in the Maude specification derived from the original 
use-case informal specification. 

■ I. Mason and C. Talcott are also using Maude to support modeling, 
simulation and analysis of network architectures and communica- 
tion protocols taking into account resources, such as nodes, LANs 
and interfaces, network failures and their recovery, and composable 
protocols [52]. Their goal is to develop a generic infrastructure in 
which a variety of protocols can be modeled, simulated, and ana- 
lyzed in Maude. To test their ideas, they have applied them to the 
Hello subprotocol of PIM-DM. 

■ I. Pita and N. Marti-Oliet have used the refiective features of 
Maude to specify the management process of broadband telecom- 
munication networks [64, 65]. 

■ D. Basin and G. Denker have given an in-depth experimental com- 
parison of the advantages and disadvantages of using Maude versus 
using a lazy functional language like Haskell to analyze security 
protocols [5]. On the Maude side, this work contains valuable 
new optimization techniques for efficient model checking analysis 
of protocols. 

5.3. AGENT AND MOBILE LANGUAGES 

Rewriting logic and Maude have also been used to give a formal ex- 
ecutable semantics to different agent, actor, active network, and mo- 
bile programming languages, and to develop formally-based optimization 
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techniques for some of these languages. Furthermore, we are currently 
extending Maude into the Mobile Maude language. 

■ As already mentioned, S. Nakajima [59] has used rewriting logic to 
give semantics to the calculus of mobile ambients of Cardelli and 
Gordon [10]. 

■ Ishikawa et al. [39] have given a Maude specification of a represen- 
tative subset of the GAEA language [61], a refiective concurrent 
logic programming agent language for AI applications based on a 
new paradigm called organic programming. 

■ C. Gunter, P. Kakkar, M.-O. Stehr, C. Talcott, and I are currently 
developing an executable formal definition of the PLAN active net- 
work programming language in Maude that can be used as a PLAN 
simulator (PLAN does not have a simulator at present) and as a 
formal tool to analyze PLAN programs. 

■ I. Mason and C. Talcott [51, 53, 70] use rewriting logic to give 
semantic definitions of actor languages, and to “compile away” 
certain language features by defining semantics-preserving trans- 
lations between actor languages that are formalized as translations 
between their corresponding rewrite theories. 

■ van Baalen et al. [2] have used Maude to give a formal semantics 
to, and to analyze, key fault-tolerant protocols in the DaAgents 
mobile agent system. Their analysis, which includes detailed anal- 
yses of the protocols’ behavior under different fault models, has 
revealed mistakes and inconsistencies in the protocols’ informal 
specifications. 

■ Finally, as further explained below, we are using rewriting logic 
and Maude not only to specify mobile computations, but also to 
program them in Mobile Maude. 

Mobile Maude 

As already mentioned, Maude can be used not only for specifying 
distributed object systems, but also for programming them. At SRI, 
Francisco Duran, Steven Eker, Patrick Lincoln and I are currently ad- 
vancing the design and implementation of Mobile Maude [29]. This is an 
extension of Maude supporting mobile computation that uses refiection 
in a systematic way to obtain a simple and general declarative mobile 
language design. The two key notions are processes and mobile objects. 
Processes are located computational environments where mobile objects 
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can reside. Mobile objects can move between different process in differ- 
ent locations, and can communicate asynchronously with each other by 
means of messages. Each mobile object contains its own code — that is a 
rewrite theory TZ — metarepresented as a term TZ^ as well as its own in- 
ternal state. In this way, reflection endows mobile objects with powerful 
“higher-order” capabilities whithin a simple first-order framework. 




Figure 2 shows several processes in two locations, with (mobile) object 
o3 moving from one process to another, and with object ol sending a 
message to o2. 

We expect that Mobile Maude will have good support for secure mo- 
bile computation for two reasons. Firstly, mobile objects will communi- 
cate with each other and will move from one location to another using 
state-of-the-art encryption mechanisms. Secondly, because of the logical 
basis of Mobile Maude, we expect to be able to prove critical properties 
of applications developed in it with much less effort than what it would 
be required if the same applications were developed in a conventional 
language such as Java. 

6. CONCLUSIONS 

I have explained how rewriting logic and Maude can be used to specify, 
execute, and formally analyze distributed object-based systems using a 
flexible range of formal methods, tools, and specification logics. I have 
also summarized a fairly extensive body of work by different authors 
applying rewriting logic and Maude to distributed software architec- 
tures and components, to communication protocols and networks, and 
to agent and mobile languages. 
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This paper is a snapshot of work in progress. However, I hope to have 
given enough evidence to support the view that — thanks to the efforts of 
researchers in the US, Europe, Australia, and Japan — rewriting logic is 
well suited as a semantic framework for object-based distributed systems. 
Of course, some of the most exciting work remains ahead of us, including: 

■ Uses of Maude in internet programming and mobile computation, 
based on the upcoming release of Maude 2.0 and the Mobile Maude 
language currently under development. 

■ Further advances in property-oriented specification logics comple- 
menting rewriting logic, including development of model checking 
and proof techniques supported by adequate tools. 

■ More applications of rewriting logic and Maude to the design, anal- 
ysis, and verification of secure distributed systems at all levels of 
abstraction: software architectures, protocols and networks, and 
mobile code. 

■ Uses of Maude as a forma meta-tool to build both a richer for- 
mal environment of tools for Maude, and a wide range of domain- 
specific formal tools. 
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Abstract We propose a formal real-time semantics for UML statecharts aimed 
at the requirements level. A requirements-level model assumes perfect 
technology and has a considerably simpler semantics than an implemen- 
tation level model. Our semantics is an adaptation of the Statemate 
statechart semantics, with local variables, real time, identifier address- 
ing, point-to-point communication, synchronous communication and 
dynamic object creation and deletion. We start with an informal com- 
parison of Statemate and UML statechart semantics and then give a 
formalisation of our semantics in terms of labelled transition systems. 

Keywords: statecharts, UML, formal semantics 

1. INTRODUCTION 

Statecharts were introduced by Harel [5] to model the behaviour of ac- 
tivities in the structmed analysis approach Statemate [8]. They have 
been adapted in many object-oriented design notations, including the 
UML [14], but with an informally or undefined semantics that appears 
to be quite different firom the Statemate semantics. 

In this paper, we define a formal semantics for UML statecharts based 
upon the STATEMATE semantics for two reasons. First, a formal seman- 
tics allows model checking UML models used for requirements specifica- 
tion. This differs from similar research done for Statemate [3] in that 
it works with 00 models and it differs from similar work [11] with UML 
in that it is at the requirements level, not at the implementation level. 
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Table 1 Differences between Statemate and requirements-level UML 



Statemate activity chart + statechart 


UML class diagram -h statechart 


separation of data state/process and 


encapsulation of data state/process and 


control state/process 


control state/process 


channel addressing 


identifier addressing 


broadcast 


point-to-point 


instance level model 


type-instance distinction 



(A requirements-level model focusses on the design and assumes per- 
fect technology [13], whereas an implementation- level model does not, 
since it is especially concerned with implementing a design.) Second, 
such a semantics allows to classify the differences between structured 
and 00 semantics of statecharts in two dimensions: structured versus 
00 models and requirements level versus implementation level. 

Tables 1 summarises the difference between our 00 semantics and 
the structured Statemate semantics. Firstly, object-oriented models 
encapsulate data manipulation, control and data state into objects (as 
operations, statecharts, attributes). Structured Yourdon-style models 
separate them into data processes, control processes and data stores, re- 
spectively. Statemate simulates local variables of statecharts by means 
of input and output flows accessible to the statechart. This means that 
in Statemate “local” data is really data present in communication 
channels between activities. Statemate models (as all other struc- 
tured models) have separate activities where UML models only know of 
data manipulation local to an object. The absence of separate activities 
and the use of true local variables in the UML considerably simplifies 
our semantics w.r.t. the Statemate semantics. Secondly, to communi- 
cate information to a destination, objects in 00 models must use the 
identifier(s) of the destination(s) whereas processes in structured mod- 
els must use the identifiers of the communication channels. As a con- 
sequence, communication in 00 models is point-to-point, whereas in 
structured models, it is broadcast. Finally, object-oriented models use 
the type-instance distinction, which is absent from structured models. 
This means that in our semantics, we can deal with dynamic creation 
and deletion of instances. 

Table 2 summarises the differences between our semantics of UML 
statecharts and the semantics indicated informally in the OMG docu- 
mentation [14]. The differences follow from the fact that we define a 
requirements-level semantics whereas the OMG defines an implementa- 
tion-level semantics. The OMG UML 1.3 semantics makes the assump- 
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Table 2 Differences between requirements and implementation-level semantics 



requirements-level semantics 


implementation-level semantics 


perfect technology 


imperfect technology 


input is event set 


• input is queue 


system reacts to all events in input 


• system reacts to one event in input (the first) 


event exists for one step 


• event exists arbitrary long 


instantaneous communication 


• non-instantaneous communication 


communication arrives always 


communication may get lost, or arrive at wrong des- 
tination 


one global clock 


many local clocks 


no clock drift 


clocks may drift 


action is instantaneous 


• action takes time 


unlimited concurrency 


• limited concurrency, i.e., threads of control with in- 
terleaving per thread (one thread per active object) 



tions marked by a bullet in table 2. Our semantics, like Statemate, 
makes all of the assumptions in the left-hand column. 

Together, tables 1 and 2 factorise the differences between the State- 
mate and UML semantics of statecharts into two groups: the differ- 
ences between structured and 00 models and the difference between 
requirements-level and implementation-level semantics. On the other 
hand, Harel and Gery [6] state that the main difference is that UML stat- 
echarts use run-to-completion (RTC) whereas Statemate statecharts 
do not. RTC is one possible way to maintain atomicity of transitions 
at the implementation level. In an RTC semantics, an event can only 
be processed, if processing of the precious event input has completed 
(all triggered transitions have been completely taken). Sending an asyn- 
chronous message is considered to be completed when the message is 
sent; calling a synchronous operation is considered completed when the 
called operation is completed, and this requires maintaining a call stack. 
Statemate has no synchronous communication and hence no call stack. 
In our opinion, RTC is a minor difference compared to the differences 
identified by us. 

We now briefly sketch some design choices we have made in defining 
a semantics. The following choices have to be made for any semantics 
of statecharts, regardless of semantic level or design paradigm (see also 
Von der Beeck [2]): 

- We specify both a clock-synchronous and clock-asynchronous se- 
mantics [8]. In the clock-synchronous semantics, the system starts 
processing its input only at the tick of the clock. In the clock- 
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asynchronous semantics, the system starts processing its input as 
soon as it receives it. In the OMG semantics of UML, this issue is 
ignored. 

- In synchronous communication, the caller must wait until the callee 
has finished processing the communication. In asynchronous com- 
munication, the caller continues without waiting for the receiver 
to finish processing the communication. Statemate only uses 
asynchronous communication. We follow the UML in defining a 
semantics for both. We show that in our requirements-level se- 
mantics, synchronous communication is only possible with a clock- 
asynchronous semantics. 

- Like the UML [14], we allow no compound triggers, no negated 
trigger events, and only a single entry and single exit action. 

- We allow for the case that the action expressions of a transition 
contain sequence, interleaving and parallel operators. The example 
action language that we use only contains the sequence operator, 
but our semantics can deal with the generalised case. Parallel 
actions that interfere lead nondeterministically to different possible 
states. 

- Updates to variables are made at the end of a step. This way no 
inconsistent value can be read. 

- We assume a given priority preorder on transitions, and do not 
commit ourselves to any particular one. Possible priority preorder 
are the Statemate one (a higher level transition has priority over 
a lower level one) and the UML one (a lower level transition has 
priority over a higher level one). 

- In the UML, a distinction is made between active and passive 
objects. Active objects have computing resources, passive objects 
have not. At the requirements level, all objects have computing 
resources, so we only have active objects. 

As most other statechart semantics, ours preserves causality (effect should 
not be contradictory to cause). We allow instantaneous states. 

The following UML statechart constructs could be added to our require- 
ments-level semantics without difficulty, but to simplify the exposition 
we omitted them: 

- Deferred events. These can be simulated by regenerating an event 
as often as it is to be deferred. 
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- Parametrised events. These can be simulated by sets of para- 
meterless events (one for every combination of parameter values). 
The resulting state space may be infinite (making model checking 
impossible). 

- A taxonomy for events. This is an abbreviation mechanism that 
allows one to reduce the number of transitions in a statechart. It 
does not add expressive power. 

- Activities (actions that take time). These can be simulated by 
instantaneous start and finish events. 

- Dynamic choice points. Adding this UML construct would mean 
that a step is executed in two parts, separated by the dynamic 
choice point. Dynamic choice points can be simulated by adding 
an intermediary state. 

- Synchronisation states. (These pseudo states are used to mimic 
a monitoring or semaphore construct.) We regard this to be an 
implement at ion- level construct. This construct can be simulated 
by a join (a transition with multiple source states) with a counter. 

- History states. These can be simulated by (re)defining an entry 
function (see e.g. Damm et al. [3]). 

Related work. Our LTS semantics is the UML analogon of the 
LTS semantics for Statemate statecharts defined by Damm et al. [3]. 
Due to the differences between UML and Statemate discussed above, 
our semantics is considerably simpler. Our semantics is based upon an 
earlier requirements-level UML semantics with simple state-transition 
diagrams given by Wieringa and Broersen [17]. All other approaches 
known to us are implementation-level semantics. 

Latella et al. [10] use hierarchical automata to define a formal seman- 
tics for one UML statechart. The step semantics they define resembles 
our semantics of a step, but they do not define other aspects of behaviour 
(for example, communication). 

Lilius and Porres [11] give an operational semantics for the original 
UML definition [14] by defining an algorithm for the execution of a step 
in pseudo-code. It is however unclear how to derive a Kripke structure 
from this algorithm. This is important since the authors have built a 
model checker based on their semantics. The authors do not define other 
aspects of behaviour (e.g. creation, deletion, communication). 

Reggio et al. [16] give a semantics for one UML statechart belonging 
to an active object by defining a labelled transition system. They stick 
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as close as possible to the informal standard definition, eliminating in- 
consistencies, but they nevertheless have to make a number of choices 
mostly due to the implementation level. They do not define communi- 
cation. 

Harel and Kupferman [7] give an executable object model for a sim- 
plified version of a UML like system. They consider simple Mealy ma- 
chines, whereas we consider statecharts. They focus on communication 
between different objects and on the possibilities of deadlock in a clock- 
asynchronous semantics. We, on the other hand, focus on communica- 
tion at the requirements level where no deadlock is possible, and consider 
both a clock-synchronous and clock-asynchronous semantics. 

In section 2, we summarise the necessary syntax definitions of UML 
statecharts. In section 3 we generalise the definition of a step so that it 
applies to structured and object-oriented design approaches and is inde- 
pendent from semantic level. In section 4 we then define the execution 
semantics of one statechart in terms of a labelled transition system. In 
section 5 we add creation and deletion action expressions and communi- 
cation between statecharts. We end with a discussion and conclusions. 

2. STATECHART SYNTAX 

Most of the definitions in this section are adapted from Damm et al. [3] 
and Pnueli and Shalev [15] with minor changes to deal with final states 
and completion events in the UML. The paragraph on time expres- 
sion is new. A statechart SC is a collection of state nodes, hierar- 
chically related, and connected by edges. It is described by the tuple 
SC = {Nodes ^ Edges ^ Events^ Guards , Actions , Var), with Nodes the set 
of state nodes. Edges the set of edges. Events the set of primitive event 
expressions. Guards the set of guard expressions. Actions the set of ac- 
tion expressions, and Var the set of local variables. We assume a set 
Names to label the edges. 

State nodes. The function children : Nodes — > "INodes defines for 
each state the set of children of that state (its immediate substates). 
If s G children {s^)j we call s' the parent of s. If a state node has no 
children, it is basic. Otherwise, it is a composite state node. A composite 
state node is either an AND or an OR state node. When the system is 
in an OR state node, it is in one of its children. When the system is 
in an AND state node, it is in all of its children. The function type : 
Nodes {basic, AND, or} assigns to every state node its type. 

Function children defines a partial ordering on the state nodes: 



s < s 



Reflexivity 
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5 < 5' if 5 G children {s') 

s < s' A s' < s” s < s" Transitivity 

If 5 < 5' we say that s' is the ancestor of s. If either s < s' or s' < s^ 
we say 5 and s' are ancestrally related. 

There are some special state nodes. We assume a unique root state 
node, denoted root. We require root to be an OR state node. Another 
special state node is the final state node. If state node s is an OR state 
and one if its children is a final state node, that state node is denoted 
finals. A final state node must be basic, and no edges emanate from it. 
Obviously, finals ^ finals and finals < s. 

The partial function default : Nodes — > Nodes identifies for each OR 
state node s one of its children as the default state node, that is entered 
when s is entered. 

For a set of state nodes X C Nodes ^ the least common ancestor lca{X) 
is the state I G Nodes such that: 

yx e X • X < I 

Vy G Nodes • (Vx ^X-x<y)=^l<y 

Two state nodes 5,5' are orthogonal., written s A. s', if s and s' are not 
ancestrally related and their lea is an AND state. 

A set of state nodes X C Nodes is consistent if, for every every pair 
x,y G X, either x and y are ancestrally related or x and y are or- 
thogonal. A configuration is a maximal consistent set of state nodes. 
Configurations are valid ‘states’ of the statechart. 

In order to deal with UML completion events, we define predicate 
stopped{C,s) that is true if in configuration C (composite) state s is 
terminated: 



stopped{C,s) = < 



false, 

final5 G (7, 

Vx G children{s) • stopped{C,x), 



if type{s) = BASIC 
if type{s) = OR 
if type{s) = AND 



Edges. An edge is a relation from one set of state nodes (source) 
to another (target). An edge has a unique name. It is labelled with an 
event expression, a guard expression and an action expression. (Infor- 
mally, when the event specified by the event expression occurs, and the 
guard expression evaluates to true, the action expression is evaluated.) 
Formally, Edges C Names x FNodes x {Events Uib) x Guards x Actions x 
FNodes. For every t = (n,X, e,g, as, Y), let name{t) = n, source{t) = 
X, event{t) = e, guard{t) = g, action{t) = as and target{t) = Y . 
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We require that source{t) and target {t) are non-empty consistent sets of 
state nodes. 

For a given transition t whose source is composite state 5, a special 
event that may be used to label Ms This we call the completion 
event. It occurs if and only if in a given configuration ( 7 , stopped {C^ s) 
becomes true. 

The scope of a transition t is the most nested OR state that contains 
both source{t) and target{t). It is the most nested state of the statechart 
that is not exited or entered when the transition is taken. 

Two transitions are consistent if they are equal or their scopes are 
orthogonal. A set of transitions T is called a consistent set if t\ and t2 
are consistent, for every t\^t2 E T. Denote by consTrans{T) the set of 
all transitions that are consistent with every t ^ T. Note that if T is 
consistent, then T C consTrans(T). 

Next, we assume a priority ordering :< on the transitions. We need 
an order to choose some transitions if we have a non-consistent set of 
transitions. We assume to be a total pre-order. We write t :< t' to 
denote that t has higher or the same priority as t'. 

Syntax of action expressions. The set of basic action expressions 
for a given statechart SC, denoted Actions{SC), is defined as follows. 

v:=exp where v G Var(SC) 

a;a^ where a £ Actions (SC) 

ref id: =create (Class) where refid G Var(SC) 

delete (id) 

send id. signal where signal is a signal reception of object id 

id . oper where oper is an operation of object id 

This syntax may easily be extended to incorporate more advanced fea- 
tures. In section 5 we will explain the meaning of Class and id. 

Time expressions. In the UML there are two kinds of time ex- 
pressions: absolute and relative. An absolute time expression references 
the current time. It is specified by the UML when(cond) construct (e.g. 
when(time=12:00:00h)). A relative time expression references the time 
relative to some occasion. It is specified by the UML after(^exp) con- 
struct (e.g. after(IOs), which is true 10 seconds after the source state has 
been entered), where texp is of type N. 

Below, we will define a translation of when and after into basic guard 
expressions (i.e. not containing A,V,-i), that we call basic clock con- 
straints. We assume that each basic clock constraint references a clock 
c of type real, and that the form of the constraint is c < n or c > n 
where n G N. 
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We translate an absolute time expression when (cond) into a guard 
expression that references a global clock (the current time) by treating 
cond as guard expression. We introduce special clock variable ct to 
represent the current time. At the beginning of the execution of the 
statechart, this clock is initialised with the current time. 

We translate a relative time expression after{texp) as follows into a 
guard expression that references a local clock. We regard after as a 
special kind of event label that can only label transitions that have a 
single source. Let x = source {t). We introduce a special clock variable 
tmrx that denotes a local clock (a timer), that will be reset every time 
state node x is entered. The event aher[texp) is replaced by guard 
expression [tmrx > texp]. 

Note that a basic clock constraint of the form tmrx ^ where tmrx 
is a timer and n E N, does not make sense. If state node x is entered, 
tmrx is set to zero; hence, the basic clock constraint will be always true 
then. 

In Statemate, scheduled actions may be used. A scheduled action, 
in Statemate syntax denoted sc(a, texp)^ means that action a must be 
done after delay texp. This can be specified in the UML using the after 
construct: after(^ea:p)/a. 

3. GENERIC STATECHART STEP 
SEMANTICS 

In this section and the next one we give a requirements-level semantics 
for one statechart. In this section we present the definition of a step. It is 
generic and independent from whether we follow a structured or object- 
oriented design approach. It is simpler than the Statemate definition 
of a step [8] [3] because there are neither negative nor compound events 
in the UML. 

We define how to compute a step, given a configuration C and a 
set of input events I. This step must obey several constraints, such as 
maximality and consistency and priority. After Pnueli and Shalev [15], 
we define a step both declaratively and operationally. Note however that 
we do not define a superstep in this way, as they do, and that we take 
into account priorities, whereas they do not. 

First, we define all enabled transitions En{C, I): 

En{C^I) = {t I source{t) C C A event {t) G I A guards {t)} 

where guard(j{t) represents the evaluation of guard (t) in valuation a. 
(See section 4 for the definition of a valuation.) 

We construct a step in an incremental way, by adding transitions that 
are consistent. To aid in this construction, we define function addToStep 
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Figure 1 nextstep{C , I): algorithm to compute steps 
let T = 0; 

while T C addToStep{T) do 
choice t G high{addToStep{T) — T); 
let T = TU {4 
endwhile 
return T 



as follows. Suppose we have decided to take a set of transitions T. The 
function addToStep{T) gives us the transitions that are enabled and are 
consistent with T. The function addToStep(T) is defined by: 

addToStep(T) = En{C^I) H consTrans{T) 

A step T* must satisfy the following constraints: 

1 Enabledness All transitions of the step must be enabled. 

2 Consistency All transitions taken in T* are consistent with each 
other, i.e., each of them could be added. 

3 Maximality The step is maximal, i.e., every transition that could 
be added is already part of the step. 

4 Priority If an enabled transition is not in the step, then there must 
a transition in the step that is inconsistent and has higher or the 
same priority. 

We formalise these constraints as follows: 

T* C En{C,I) Enabledness 

T* C consTrans{T*) Consistency 

addToStep{T*) C T* Maximality 

yt G En{C ^ I)—T* 3t^ G T*- 1 0 consTYans{{t^}) At':<t Priority 

Note that the first three constraints are equivalent to the fixpoint equa- 
tion T* = addToStep{T*). 

Next, we give a nondeterministic algorithm nextstep{C ^ I) to compute 
the maximal, nonconfiicting step given a configuration C and a set of 
input events I (see Fig. 1). In the definition of the algorithm, we use a 
set high{T). This set high{T) C T contains the transitions of T with 
the highest priority: 

high{T) = {teT\yt'eT^t<t^} 
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Now that we have defined a step in two diff’erent ways, we show the 
consistency of both approaches. We call a step T* constructible if and 
only if T* can be constructed via procedure nextstep{C ^ I). 

Proposition 1. T* satisfies the constraints 1-4 iff T* is constructible. 

Proof. Omitted due to space limitations. See [4]. □ 

4. STATECHART LTS SEMANTICS 

We now present two different ways of executing a step. In the clock- 
synchronous semantics, a step is executed when the clock ticks. In the 
clock- asynchronous semantics, a step is executed immediately when new 
events arrive. Then the system becomes unstable and reacts infinitely 
fast to become stable again. These two semantics are borrowed from 
the Statemate semantics. The major differences with Statemate se- 
mantics are the different treatment of termination in the UML and the 
absence of a separate activity model in the UML. Besides, our definition 
of real time is different from the Statemate definition. 

4.1. CLOCKED LABELLED KRIPKE 
STRUCTURE 

We assume a typed set of variables Var and a typed data domain V. A 
valuation function a : Var V assigns to every variable a value. The 
set of valuation functions defined on Var is denoted E( Var). Every state 
of the clocked labelled Kripke structure is a valuation a of the variables 
Var. Prom now on, we will use the term ‘valuation’ instead of ‘state 
of a clocked labelled Kripke structure’ to avoid confusion with the state 
nodes of statecharts. Valuations are connected by transitions labelled 
with actions out of set Act. 

A clocked labelled Kripke structure (CLKS) is a tuple 
{Var,Act^—> ^ci^ao) with: 

- Var the set of variables, 

- Act the set of actions, 

- — > C E( Var) x FAct x S( Var) the transition relation, 

- ci : a CC a function that assigns a conjunction of basic clock 
constraints to every valuation, the clock invariant, 

- (Jo G S( Var) the initial valuation. 

Set CC denotes all possible conjunctions of all basic clock constraints. 
Instead of (cj, A,(j') G — we write a-^a' . The clock invariant is a 
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conjunction of basic clock constraints of the form c < n. Given config- 
uration a{cfg), for every transition t with source{t) C a{cfg), that has 
a guard expression containing a clock constraint of the form c > the 
clock invariant cv contains a basic clock constraint c < n. Below, we 
will see that the clock-invariant helps in raising a temporal event (see 
the definition of time)- This is necessary for the clock- asynchronous 
semantics. It is not necessary for the clock-synchronous semantics, since 
at every tick of the clock input is processed, but it helps in clarifying 
the clock-synchronous semantics. 

For readers familiar with timed automata [1] or clocked transition 
systems [12], note that we do not have defined clock constraints on tran- 
sitions of the CLKS. Instead, clock constraints are present as guard 
expressions in the statechart! We could have defined clock constraints 
on the transitions of the CLKS, but this would have complicated our 
semantics considerably without adding new information to the semantic 
structure. The set of clocks to be reset is implicit; see the definition of 
copy below. 

When interpreting a statechart in an LTS, the set of variables Var 
comprises the variables of a statechart SC (denoted Var{SC))^ and a 
copy of these variables, denoted by priming the original variables. Up- 
dates are made to the primed variables, to ensure that actions can only 
read the values variables had at the beginning of a step. 

Special elements of Var are the variables cfg and inp denoting resp. 
the current configuration of the statechart and the input of the state- 
chart, represented as a set of events. Next, we have a clock variable 
ct that denotes the current time, and a set of clock variables tmr that 
contains all timers tmrx^ where x is the source of a transition that has 
a guard expression referencing local clock tmrx (see section 2). 

We only consider Kripke structures that satisfy the constraint that all 
relevant completion events are in the input: 

{^/^ I stopped {a (cfg), s) A s e cr{cfg)} C cr{inp) 

We let set Act be the union of the sets Events^ Actions^ and Guards, 
We assume a function act : Edges — > Act that, given a set of edges, 
returns the set of actions that are in the set. This function will be used 
to label the transitions in the CLKS with actions. 

Next, we sketch briefiy how action expressions are evaluated. If a 
is an action expression and g a valuation, then |a|cr is the valuation 
resulting from the evaluation of expression a. Updates are made to the 
primed versions of variables only. For example: 

[x := exp}a = a[x' /{expja] 

[action] actions equenceja = [actionja] [actions equenceja 
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The meaning of the x/val construct on valuations is defined as follows; 

Finally, the initial valuation (Tq must satisfy (Jo{cfg) = dcomp{{root}), 
ao{input) = 0, G tmr • (jQ{t) = 0, and ct and the local variables must 
be given an appropriate value. Function dcomp computes the default 
completion of a set of state nodes (see e.g. [15], [3] for a definition). 



4.2. BASIC CLOCK-SYNCHRONOUS 
EXECUTION 

The relation of the Kripke structure is the union of three relations 

time 5 -^change-) ^nd step^ defined below. Not every sequence of 
transitions out of these three sets satisfies the clock-synchronous seman- 
tics. Sequences in the clock-synchronous semantics are cycles, where a 
cycle describes the execution of the CLKS during one time-unit (from 
one clock tick to another). A cycle is a non-empty sequence of time 
steps (which represent the elapsing of time), possibly interleaved with 
change steps (which represent changes in the environment), followed by 
the taking of a step at the tick of the clock: 



cycle 



_ dp y 



time] ^ change] 



Si, 



time] ^ change 



' time] 



' step 



where = 1- Relation time corresponds to the elapsing of time. 

Relations change represents a change in the environment. There are 
three possible changes: either an external event occurs ( — > event) ^ a value 
change occurs ( value) ^ or a temporal event occurs ( — > Ume-out)- 



^ S. / 

^ time^ 




cr' = a[ct/{a{ct) + S)^ 

^tmrx\tmrx£tmr^'^'^x / “b ^)] 




A 


Vs G [0, J] • cv' where 

a" = a[ktmr,\tmr,etmrtmrx/{a{tmrx) + e)] 


^ change 


= 


^ event ^ ^ value ^ ^ time-out 


^ ^ event ^ 




3E C Events • E ^ ^ 

A cr' = a[inp / (a{inp) U E)] 


^ ^ valued 




a ^ a' 




A 


= <y'{cfg) 




A 


a{inp) = (j'{inp) 




A 


\/tmrx G tmr • a{tmrx) = a'{tmrx) 


^ ^ time-out^ 


4:^ 


a = a' 
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A $a” • a timecr” 

Relation time represents the increase of the global clock ct and all 
timers tmvx by 5^ provided that during this period all clock invariants 
hold. The ampersand symbol denotes that all updates to all timers are 
made simultaneously: 

— ^\^firstidl '^0,^'firstid • • • ^lastid/ '^(^kastid] 

where ID = {firstid . . . lastid}. Relation event extends the current 
input set nondeterministically with a set E without changing the system 
state. Relation — > yaiue indicates a value change of one or more local 
variables. Relation — > time- out represents that a temporal event (time- 
out) occurs iff a time step is not possible. Next, we define the — > step 
relation, corresponding to the execution of a step. 

_ _Av .V 

— ^ nexistep? ^ copy 

^ A = act{T*) 

A a' = a"[cfg/nextconfig{(j{cfg), T*), inp/<l)] 
where isStep{T*) and a" = lactions{T*)}a. 
^ cr' = a[ KeVar{SC)y/(^{'^') 

^tmrx\tmrx£tmrAx£(T{cfg) 

Relation nextstep relates valuation a with a' iff given input events 
a{inp) in configuration cr{cfg) step T*, satisfying isStep{T*) is taken, 
and the actions of T* are evaluated, such that valuation a” is reached. 
Next, the configuration and inputs are updated, the input is removed, 
and valuation a' is reached. (See e.g. [3] for a precise definition of func- 
tion nextconfig.) Predicate isStep{T*) is true iflF step T* satisfies the con- 
sistency, maximality and priority constraints, given configuration cr{cfg) 
and set of inputs a{inp). Whether completion transitions have priority 
over non-completion transitions, depends on the definition of the prior- 
ity relation ■<. Function actions (st), given a set of transitions, returns 
a sequence of their actions, respecting the order of the action within 
each transition, but nondeterministically choosing an order between the 
transitions themselves: 

actions{T) = action{ti ); . . . ; action{tn) {ti, . . . , tn} = T 

Relation — > copy represents that all unprimed variables are updated with 
the values of their primed counter parts and all relevant timers are reset. 



^ step 

^ A, / 

^ ^ nextstep^ 
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4.3. BASIC CLOCK-ASYNCHRONOUS 
EXECUTION 

The — > relation of the CLKS is a union of the -^change 

superstep relations. Like in the clock synchronous semantics, an execu- 
tion sequence is a sequence of cycles. Now, however, a cycle describes the 
execution of the CLKS from the end of one reaction until the end of the 
execution of the next one. A cycle is a sequence of time steps, followed 
by a change step, immediately followed by the reaction of the system, 
a superstep. A superstep is a chain of steps. The fact that a chain of 
steps is taken, rather than a single step, is due to the perfect technology 
assumption (reactions happen infinitely fast) and the assumption of the 
clock- asynchronous semantics that a change in the environment, includ- 
ing one caused by the system itself, is immediately reacted upon. This 
implies that all completion events are immediately reacted upon; hence 
in all valuations the configuration of the statechart is stable (does not 
contain a final state node). Another effect of this definition is that a 
superstep may be infinite. In that case, we say the superstep diverges. 



^ time 5 ^ change 5 ^ superstep 

•^1 V V 



where A = A\ U . . . U An and stable{a^{cfg),a'{inp)) must hold: 



stable{C^ I) (V5 E C • stopped{C, 5 )) A / = 0 A En{C, /) = 0 



The superstep stops if the current configuration is stable and there are 
no more inputs and no more enabled transitions. The other definitions 
are as before. 



5. COMMUNICATING STATECHARTS 

We now add creation and deletion of objects, absent from Statemate 
semantics, and synchronous and asynchronous communication. State- 
mate only uses asynchronous communication. Our semantics leans 
heavily on the use of object identifiers. 

Assume a set of Classes Class and a set of object identifiers OLD. Ev- 
ery class c has a statechart definition associated, whose root is identified 
as c.root. Now that we have multiple objects instead of one, we index 
the special variables cfg^ inp and tmr with the object id’s. So cfg[id] 
denotes the configuration cfg of object id. We assume that all variables 
used by objects are unique, including clock variables. (Variables can be 
made unique by simply putting the object id in front.) We denote the 
local variables of an object id with Var{id). As before, every variable 
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V E Var{id) has a primed version, but now, in addition, every set of in- 
put events inp[id] has also its primed version inp^[id], because we define 
communication between statecharts. 

We only consider CLKSs for which it holds that for every existing 
object, all relevant completion events are in its input. The formalisation 
of this, and the definition and formalisation of the initial valuation of 
the CLKS are straightforward generalisations of the single-object case. 
We refer the interested reader to [4]. 



5.1. CREATION AND DELETION 

The meaning of action expression ref id:=create (Class) is that an 
object of class Class is created with a new identity whose value is as- 
signed to variable refid. Action expression destroy (id) means that 
object id is destroyed. 

In order to give a formal semantics for creation and deletion we make 
use of two predicates. Predicate Exists{id) is true iff an object with 
identifier id exists. Predicate Used{id) is true iff there exists or ex- 
isted an object with identifier id. The obvious constraint holds that 
Exists(id) => Used{id). 



\refid := create{Class)\G 



\destroy{id)\a 



a [ cfg [id] / dcomp ( { Class . root } ) , 
mp[id]/0, 
refid/id^ 

Exists [id) / true 

Used[id)/true] if -^Useda[id) 

a[Exists[id) / false] if ExistSa[id) 



A new object id can be created only if id is not used before. If object 
id can be created, then it is initialised by setting its configuration and 
set of input events, and updating predicates Used and Exists. 

5.2. COMMUNICATION 



Clock-synchronous model. In the clock-synchronous model, we 
only allow asynchronous communication (the send action). The reason 
is that in synchronous communication, the caller must wait until the 
callee returns. In the clock-synchronous model, the callee is performing 
its own step when it receives the call and can respond to the call only in 
the next step at the next tick of the clock. Since in our requirement s- 
level semantics, a transition must be taken in zero time, the caller cannot 
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wait for the callee to do its work. We therefore have no synchronous 
communication in a clock-synchronous semantics. 

As in the clock-synchronous model of the previous section, the 
relation of the CLKS is the union of three relation timei change ^nd 
— > step- Again, every sequence of the CLKS must be a sequence of cycles, 
where a cycle is as defined in the previous clock-synchronous model. The 
three relations have to be redefined to take into account the fact that we 
now have a set of objects, rather than one object. Redefinition of the first 
two relation is straightforward, since the only extension is quantifying 
over all existing objects. See [4] for a full definition. Relation step 
now becomes: 



^ step 

_ A , / 

^ ^ nextstep^ 



G 



copy^ 



^ V . V 

— ^ nextstepi ^ copy 

^ T* = [Jid\ExistSa{id) '^id 

A A = act{T*) 

^ O' — G \ ^id\ExistSa{id) 

cfg [id]/ nextconfig {G{cfg [id ] ) , )] 

where for every id, ExistScr{id) => isStep{T^^)^ 
and a" = {actions {T*)J g 

^ ~ ^id\ExistSa{id) 

^v\v£Var{id)'^ /o{v ), 

inp [id] /g{ inp' [id] ) 
inp'[id]m 

^ tmrx I tmrx G tmr [id]Ax£a{cfg[id]) t'OlTx / 0] 



The definition of — > nextstep refiects that all existing objects dispatch 
their events at the same time. Step T* is defined as the union of the 
individual steps of the objects. The remainder of the definition is a 
generalisation of the definition of — > nextstep in the previous section. The 
copy relation is a straightforward generalisation of the counterpart 
with the same name in the preceding models. Note that the set of input 
events after a step may be filled with events generated by send actions. 

Finally, we add the semantics of a non-blocking communication by 
specifying the semantics of a send action expression. 

[send id.signaljG = G[inp^[id]/{G{inp'[id]) U {signal})] 



Clock-asynchronous model. In the clock-asynchronous model, we 
again define — > and a cycle as in the previous clock-asynchronous model, 
reusing for — > time and — > change the definitions of the previous para- 
graph. We now define the relation superstep- 
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First, observe that in the clock-asynchronous model both asynchro- 
nous and synchronous communication is allowed. Synchronous commu- 
nication is allowed because each object instantly reacts to the events it 
receives and hence always is ready to synchronise with another object. 
We assume that only a single object is active during a single step. We 
can justify this by our other assumption that single steps and supersteps 
do not take time. 

A step, executed by one object id, is defined as follows. The definition 
formalises RTC semantics. 



_ A, id , _/ 

CT A step^ 

_ A, id , _/ 

^ ^ nextstep^ 



a 



id y 



copy^ 



_ _ A, id , . id ^ 

— o r nextstepi ^ copy 

^ A = act(T*) 

A a' = a"lcfy[icl]/nextconfiff(cr(cfglid]), T*)] 
where isStep{T*) and a" = factions {T*)\a 

^ a' = a[ Kevar{id) vla{v'), 
inp [id] /a{ inp' [id ] ) , 
mp'[id]]/0] 



The above definition is a straightforward adaptation of the previous def- 
initions of step ^ nextstep and copy The change w.r.t. the clock- 
synchronous model of this section is that we now define a step for one 
object only. A superstep S' of a finite set of objects 0 will be a non- 
deterministic interleaving of supersteps of the each object in 0. The 
next definition says that in each single step of S we nondeterministically 
choose a step of some object in 0. 



_ A , _/ 

^ ^ singlestep^ 



_ A , _/ 

C' r super step^ 



A 

4:^ 



3id G OID I ExistScr{id)' 

^ AM , 



step^ 



^ ^ singlestep 



Aji » / 

^ singlestep^ 



A Vzd G OID I ExistS(ji{id)- 

stable [a' ( cfg [id ] ) , cr' ( inp [id ] ) ) 



where A = A\U . . .U An- 

What remains is to define the meaning of synchronous calls as part of 
the execution of actions {T*). If an object calls operation oper of object 
id^ then first of all id should exist, and second, id should process the 
call. Since id itself may have nonempty input, this old input should be 
remembered and placed back after id has finished executing. Together 
with step ^ this formalises RTC semantics, because it says that a call 

action is executed only when the called action is executed. 
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{id.operja = if ExistSa{id) 

A CTi - y step^2 

A cr' = a2[inp[id]/ {G2{inp[id\) \J a{inp[id]))] 
where g\ = a[inp[id]l oper] 

6. CONCLUSION 

This paper presents a formal real-time requirements-level semantics for 
UML statecharts. The step relation is specified both declaratively and 
operationally and is parametrised with respect to the priority definition. 
The most important aspect of the semantics is the definition of com- 
munication between several co-existing and cooperating objects. The 
semantics supports dynamic instantiation of objects. As explained in 
the introduction, our semantics makes it possible to identify the differ- 
ences of UML statecharts with Statemate statecharts. 

Because it is defined in terms of a transition system, our semantics 
can be used to define an execution semantics for UML models at the re- 
quirements level. In addition, it is the semantic basis for model checking 
UML requirements models. First results in model checking are reported 
elsewhere [9]. 

Future work includes, next to model checking, the study of inheri- 
tance in 00 systems by applying techniques from concurrency (similar 
to e.g. [7]). 
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Abstract This article investigates the automatic distribution and parallelization 
of object-oriented programs. We formally define a set of properties that 
allow to turn standard objects into active objects to be distributed on 
a network (local or wide area). 

We first explain a principle of seamless sequential, multi- threaded 
and distributed programming using Java, that enhances code reuse and 
code distribution. We exhibit conditions on the graph of objects to 
detect activable objects and transform a sequential program into a dis- 
tributed or parallel program using active objects. Finally, we explain 
how these properties were implemented in order to check them statically 
on a given Java program. 

Keywords: model for object distribution, formal techniques, program 
analysis 



1. INTRODUCTION 

One major issue of object-oriented programming is reusability through 
inheritance, polymorphism, and dynamic binding. This feature has also 
been studied and enhanced in the context of parallelization and distri- 
bution. Several concurrent object-oriented programming languages have 
been designed, see for instance Hybrid [30], Pool [3], DROL [34], and 
more recently Java [23]. Also, many object-oriented languages have been 
extended to address concurrency, parallelism, and distribution issues, see 
for instance ConcurrentSmalltalk [35], Distributed Smalltalk [9], Eiffel// 
[11], ProActive [14]. 
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Most of these works offer a setting for easy parallel, distributed, and 
concurrent programming, starting from a sequential application, and 
making it run on a parallel or distributed architecture. Some languages 
provide a unified syntax (no syntactic extension) for both sequential and 
parallel versions. This feature is critical for reuse. 

The concurrent object-oriented language Eiffel/ / comes together with 
a design method for concurrent applications [12]. This method promotes 
a first phase of sequential design and programming before a second phase 
that must start with the identification of concurrent activities, and then 
follows with the creation of active objects (actor- like entities [1]). This 
method can be applied to Java as well, using the ProActive library [14], 
which makes it possible to reuse sequential components in a parallel and 
distributed setting with very limited modifications. 

Another problem indeed is to be able to guarantee that the semantics 
of the original sequential version is preserved in a parallel and distributed 
setting. This problem has been tackled in various works, using different 
modelizations: 7r-calculus [29], operational semantics [27], natural se- 
mantics [5], Temporal Logic of Actions (TLA) [7]. These work are to be 
generalised, and extended to the point where the detection of parallelism 
is no longer manually achieved, but automatic. 

Toward that goal, we present in this article a parallelization and distribu- 
tion criterion based on properties of the graph of objects. The criterion 
formally expresses conditions under which objects are activable^ and so 
can be transformed into active objects of the ProActive library. The 
library itself takes care of the distribution and parallel executions: 

■ the active object can be created either within the current VM, or 
on a remote host; 

■ an active object has its own thread that executes methods invoked 
on the object in a default FIFO order; 

■ the semantics of calls to an active object are transparently asyn- 
chronous, with no code modification being required on the caller’s 
side (futures with wait-by- necessity [11]). 

We do not address the problem of compiling legacy code for high 
performance architectures; instead, we want to provide developers of 
distributed or concurrent applications with a tool that helps them in 
the process of identification and organization of parallel activities. 

The next section of this paper presents the underlying model of distri- 
bution used in the ProActive library, and details the transformations 
between sequential and parallel versions of a program. In Section 3, we 
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briefly describe semantic domains for an operational semantics of the 
Java language. Based on these domains, we formally express conditions 
for detecting activable objects on the graph of objects, and prove that 
these conditions enforce a tree-like topology of processes. We explain 
in Section 4 how we can derive an algorithm for checking our criterion, 
founded oil a static analysis of Java programs, and compare this work 
with existing static analyses. Then we discuss related work on paral- 
lelization in Section 5. Finally, we conclude and outline future work. 

2. DISTRIBUTION OF OBJECT-ORIENTED 
PROGRAMS 

In this section we give an overview of the ProActive model and library, 
and explain how one can use it as a target system for distributing appli- 
cations. We pinpoint some of the crucial features that make it possible, 
with very limited changes, to turn standard objects into active ones to 
be distributed. A typical example illustrates that technique (a binary 
search tree). 

The target model of distribution that we use has been studied and 
improved along several experiments, both practical and more formal 
[12, 13, 5, 4]. The current experimentation and implementation are 
done within Java with a library named ProActive [14]. Its main goal 
is to improve simplicity and reuse in the programming of distributed 
object systems. 

The ProActive model uses by default the following principles and fea- 
tures: 



■ heterogeneous model with both passive and active objects; 

■ sequential processes; 

■ unified syntax between message passing and inter-process commu- 
nication; 

■ systematic asynchronous communications towards active objects; 

■ wait-by- necessity (automatic and transparent futures); 

■ automatic continuations (a transparent delegation mechanism); 

■ no shared passive objects (call- by- value between processes); 

■ centralized and explicit control by default; 

■ polymorphism between standard objects and remote or thread ob- 
jects. 

A passive object is simply a standard Java object that does not have a 
thread on its own; it is passive in the sense that only calls coming from 
outside will carry and trigger their execution. An active object is, in 
an actors sense, an object, plus a thread, plus a request line of pending 
calls. Based on such an heterogeneous model (featuring both active 
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and passive objects), and thanks to the absence of sharing, a system 
is always structured as several subsystems. Each subsystem is defined 
as an active root object, and all the standard objects (not active) that 
it can reach. An automatic continuation occurs when the result of an 
asynchronous call has to be returned to another subsystem: it allows to 
automatically avoid the blocking of the current subsystem; the binary 
search tree example below (routine search) features such a case. 

Given a sequential Java program, it takes only minor modifications 
from the programmer in order to turn it into a multi-threaded, parallel, 
or distributed one. ProActive actually only requires instantiation code 
to be modified in order to transform a standard object into an active one. 
Here is a sample of code with several techniques for turning a passive 
instance of class A into an active, possibly remote, one. 

A creation of a standard object through a statement: 

A a = new A ("foo", 7) ; 
can become either: 

■ instantiation-based: 

Object [] params={"foo" , 7}; 

A a =(A) ProActive .newActive ("A" ,params, Node); 

■ class-based: 

class pA extends A implements Active {} 

Object [] params={"foo" , 7}; 

A a =(A) ProActive .newActive ("pA", params, Node); 

■ object-based: 

A a = new A ("foo", 7) ; // No change 

a = (A) ProActive .turnActive (a, Node); 

All these techniques create an active object, an instance of class A or 
pA on a given node. The node is actually a Java virtual machine that 
can be running on a remote host; the library transparently takes care 
of the distribution. The active object just created has its own thread 
that executes methods invoked on the object in a default FIFO order. 
The semantics of calls to such an object are transparently asynchronous, 
with no code modification being required on the caller’s side. 

Instantiation-based creation is much of a convenience technique. It 
allows the programmer to create an active instance of A with a FIFO 
behavior without defining any new class. In the class-based creation, 
given a class A, the programmer writes a subclass pA that inherits di- 
rectly from A and implements the specific marker interface Active. He 
or she may also provide a live method in class pA for giving a specific ac- 
tivity or managing synchronization. The object-based technique enables 
a programmer to attach an active behavior to an existing object at any 
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package f r . inr ia . proactive . examples . bineurytree ; 
public class BTree extends Object 

protected int key; // Key for accessing the value contained in this node 

protected Object value; // Actual value contained in this node 
protected BTree leftTree; // The two subtrees 
protected BTree rightTree; 

public BTree () < 

this. value - null; // On creation, the node does not contain a value 

this. leftTree - null; // Nor does it have any child 
this .rightTree = null; 

} 

// Inserts a (key, value) pair in the subtree that has this node as its root 
public void put (int key. Object value) { 

if ( (this . lef tTree==null) kk (this .right Tree*=null) ) ) < // Is leaf 
this. key - key; this. value s value; 
this . createChildren () ; 
return; 

} else if (key**this.key) { 
this. value * value; 

> else if (key<this.key) { 

this. leftTree .put (key, value); 

} else { 

this .rightTree .put (key, value); 

> 

retiirn; 

} 

// Retrieve a value from a key in the subtree that has this node as its root 
public Object get (int key) < 

if ((this.leftTree==null) kk (this .rightTree==null) ) ) { // Is leaf 
return null; 

} else if (key==this.key) < 
return this. value; 

} else if (key<this .key) < 

return this. leftTree. get (key); 

} else { 

return this . rightTree . get (key) ; 

> 

} 

// Creates two empty leaves as children 
protected void createChildren () {. 
this . leftTree » new BTree () ; 
this .rightTree - new BTree (); 
return; 

> 

} 



Figure 1 Sequential Recursive Binary Tree 



time after its creation. This is especially useful when one does not have 
access to the code that creates the standard object to be made active; 
however, this technique is not used for the distribution transformations 
described in the current paper. 

Once the active object is created, it automatically features the prin- 
ciples previously described. Among them, a few are critical for the goal 
of this paper: polymorphism between objects and active objects (allows 
the transformations), sequential processes without shared objects (no 
interleaving), asynchrony of calls and automatic continuations (avoids 
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package f r . inria . proactive . examples . binarytree ; 
import fr. inria. proactive.*; 

public class ActiveBTree extends BTree implements Active < 
protected void createChildren (){ 

this . leftTree = (BTree) ProActive .newActive ("ActiveBTree", null, null); 
this .rightTree = (BTree) ProActive .newActive ("ActiveBTree", null, null); 
return; 

}} 



Figure 2 Active Binary Tree 



package f r . inria . proactive . exeunples . binarytree ; 
import fr. inria. proactive.*; 



steuidard version 
comment the line above. 



public class TestBT 

{ public static void main (String [] args) 

•( BTree myTree ; 

myTree = new BTree () ; // Instantiating 
// To get an active version, just 
// and comment out the line below 

// myTree = (BTree) ProActive .newActive ("ActiveBTree", null, null); 
// * First parameter: get an active instance of class ActiveBTree 

// * Second (’null*): instantiates with empty (n6-arg) constructor 

// ’null* is a convenience fbr ’new Object [0]’ 

// * Last (’null*): instantiates this object on the current host, 

// within the cxirrent virtual machine 

// Use either steuidard or active versions through polymorphism 
TestBT.useBTree (myTree); 
return; 



// Note that this code is the seune for the passive or active version of the tree 
protected static void useBTree (BTree bt) 

< String si; String s2; 

bt.put (1, "one"); // We insert 4 elements in the tree, non-blocking 

bt.put (2, "two"); 
bt.put (3, "three"); 
bt.put (4, "four"); 

// Now we get all these 4 elements out of the tree 

// method get in class BTree returns a future object if 

// bt is an active object, but as System. out actually calls toStringO 

// on the future, the execution of each of the following 4 calls 

// to System. out blocks until the future object is available. 

System. out .print In ("Value associated to key 2 is "+bt.get (2)); 

System. out .print In ("Value associated to key 1 is "+bt.get (1)); 

System. out .println ("Value associated to key 3 is "+bt.get (3)); 

System. out .println ("Value associated to key 4 is "+bt.get (4)); 

// When using variables, all the instructions are non-blocking 
bt.put (2, "twoBis"); 
s2 = bt.get (2); // non-blocking 
bt.put (2, "twoTer"); 
s2 = bt.get (2); // non-blocking 
si = bt.get (1); // non-blocking 
// Blocking operations 

System. out .println ("Value associated to key 2 is "+ s2 ) ; // prints "twoTer" 

System. out .println ("Value associated to key 1 is "+ si ) ; // prints "one" 

return; 



Figure 3 Binary Tree: example of main program 
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deadlocks and allows parallelism), wait-by- necessity (automatically re- 
spects data dependencies). 

We have been studying various case studies of parallelizations, and it 
appears that, with these features, if the graph of objects at execution 
is a tree, then we can safely turn the objects of the graph into active 
ones. This property has been formally studied within various frameworks 
[4, 5, 7] and demonstrated on either examples or subsets of the model, 
and we are currently working on its generalization. The goal of this paper 
is to exploit this property in order to detect the places in a system where 
we can apply it for the sake of distribution or parallelization. Being a 
property on dynamic structures, the graph of objects and its topology 
at execution, it requires static analysis to uncover the places where it 
holds. 

Figures 1, 2, 3 present an example of parallelization: a binary search 
tree. Applied on this example, the goal that we pursue in this paper 
is to help the programmer to identify the places where the BTree class 
can be transformed into an active object while the semantics remains 
constant. In Figure 1, the system will point out that the instantiation 
of BTree: 



myTree = new BTree (); 



can be replaced with an active binary tree. So the user, possibly with 
the help of semi-automatic tools, will define the class ActiveBTree and 
replace the above instantiation with: 

myTree=(BTree)ProActive .newActive("ActiveBTree" , null, Node) ; 

The prototype we describe in this paper is able to detect that all 
instantiation sites of the Btree class in the program presented in Fig- 
ure 1 can be safely turned active, including instantiation sites within the 
method createChildren. 

3. A CRITERION FOR DISTRIBUTION OF 
OBJECT-ORIENTED PROGRAMS 

In this section, we give a condition, expressed on object graphs, for 
the identification of active objects. We show that when all objects that 
satisfy this condition (activable objects) are activated, then the resulting 
program is correct with respect to the semantics of the sequential pro- 
gram and to the constraints imposed on the runtime structures within 
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ProActive. These constraints impose that passive objects are not di- 
rectly accessible through more than one active object. To guarantee the 
correctness of the parallel program with respect to the semantics of the 
sequential one, we show that the condition implies that the topology of 
processes is a tree. This guarantees that there is no interference between 
processes. 

We formulate the condition on the basis of semantic domains that 
describe the structure of a Java interpreter. The domains are as follows : 



Env 


= Id Val 


Obj 


= Ref X Type x Env 


Objs 


= V{Obj) 


Act 


= Inst X Id X Type x Env 


Stack 


= AcV 


State 


= Stack X Objs 



The syntactic domains Type, Id and Val are respectively the set of 
classes, identifiers, and values defined by the program being parallelized. 

The interpreter is organized around an execution stack ( in the domain 
Stack) that together with a set of object (in the domain Obj) form a 
state (in the domain State). Stack elements are method activations 
that correspond to the execution of a method call. Activations are built 
up from all the elements that are needed for a method to execute: a 
program counter (element of the domain Inst)., the type of the target 
object (we omit static method invocation so any activation has a target 
object) and an environment that binds local variables to their values 
(local variables are both formal parameters and local variables declared 
inside the method body). 

We currently restrict ourselves to a subset of Java where there are 
no threads, no class methods nor class variables, and no dynamic class 
loading. For more details on the description of the operational semantics, 
the reader should refer to [6]. 

We first give various definitions (Section 3.1), then a property to be 
satisfied by an active object (Section 3.2) and finally prove facts about 
the topology of processes (Section 3.3). 

3.1. ACCESSIBILITY OF OBJECTS 

We could directly use the domains defined for the interpreter, but 
we can remark that there are two ways for a method to access an ob- 
ject: through instance variables or through local variables. In the con- 
text of parallelization we have to consider all the objects accessed by a 
process, that is all the objects accessed by the executions of a method 
invocation on a possibly active object. In ProActive, processes are as- 
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sociated to objects, so we have to consider that an object o' reachable 
by a local variable of a method activation on an object o is in the set of 
objects accessible through o. 

In order to reason uniformly about these two ways of accessing an 
object, we define a graph (the accessibility graph of a state) from an 
interpreter state. This graph represents both relations between objects 
by identical edges. We introduce a fictive node (rg) that does not cor- 
respond to an object in the object graph. It is used as a root for the 
object graph and allows us to treat uniformly nodes pointed to by local 
variables from the base activation (the method main) as we treat nodes 
pointed to by other activations. 

Definition 1 Accessibility Graph 

Given a state S = {s^h), we define the accessibility graph associated 
with S to be Gs = {Vs^Es)j such that: 

m Vs = hU where rs is a fictive node (does not correspond to 

a node in h). 

■ (o, o') E Es iff: 

— the object o points to o' (an attribute of o directly references 
o'). 

— o' is the value of a local variable^ of a method which target 
object is o (rs is considered as the target object of the method 
main^. 

The Figure 4(b) represents the accessibility graph associated to the 
state represented in Figure 4(a). 

Our criterion is based on the inspection of the memory regions read 
and written by method calls. We formally define (Definition 2) these 
domains using accessibility graphs and we call them accessibilities of 
objects: 

Definition 2 Accessibility 

For a given interpreter state S, the accessibility of an object o (noted 
As{o)) is the set of objects transitively reachable from o in the graph 
Gs- 



^We consider that there is no operation of the form t .f oo(new C( ... ) ) ; in our programs so 
that any object is at least pointed to by a local variable. Programs can easily be transformed 
to meet that requirement. 
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(c) legend 



Figure 4 Activable Objects 



3.2. ACTIVABLE OBJECTS 

Now that we have defined accessibilities, we give a property on them 
which expresses that they have the same properties as subsystems. This 
property is stated for a given interpreter state. For an object to be 
activable, it actually has to verify that property in all the states during 
its life-time (between the time it is created and the time it is no longer 
referenced or the program terminates). 

Property 1 Activable 

For a program P, in a given interpreter state S, Activables{o) iff As (o) 
is a disjoint part of the object graph: for all objects o' E As{o)^ for all 
objects o" either: o" G ^45(0) or o belongs to all the paths from o" to o' 
in Gs- 

The Property 1 states that an activable object has a self-contained 
accessibility. Any access to its accessibility must be done through it. 

We show in the next section what are the properties of the graph of 
processes induced by that property. 
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3.3. TOPOLOGY OF SUBSYSTEMS 

We have stated a condition on objects for detecting activable ones. 
We will now show that objects which satisfy this property are correct 
candidates for activation. This include three things: 

1 We have to show that the parallel program obtained is deadlock- 
free so that whenever the sequential program terminates, so does 
the parallel program. We show this by proving that the process 
topology is cycle- free (Proposition 1). 

2 We have to show that if such objects are activated, then the result- 
ing system has the same property as subsystems, that is, there is 
no shared objects between two subsystems (see [12] for a discussion 
on the topic and [5] for a formalization of this). This is expressed 
by Propositions 2 and 3. 

3 Last, we have to show that the topology of resulting processes are 
trees (Proposition 4). This guarantees that the semantics of the 
sequential program is preserved as we will explain later. 



Let’s start with a definition of subsystems. 

Definition 3 Subsystems 

Given a state 5, and an activable object n, the subsystem associated 
to n is 

Ss{n) = As{n)/ IJ As in') 

n' 6.45 (n) , n ' Activables (n' ) 

This definition only formalizes subsystems as they are introduced 
in [12, 14] and is equivalent to that given in [5] (even though we do 
not formally show this fact here). 

Before we state the propositions that state that activable objects can 
be activated, we introduce a useful lemma for proving those propositions. 

Lemma 1 Given a state 5, V ni,n2 such that Activables(ni) : 

As{ni) C ^5(7^2) or As{ri 2 ) C ^5(711) or ^5(^2) H .^^(ni) = 0 

Proof. First if n\ = U 2 then the proposition is trivially true because 
in that case As{ni) = As{ri 2 ). Ifni ^ n2 then Etssume ^^(ni) g .45(n2) 
and As{n 2 ) % ^5(ni) and As{ni)r\As{n 2 ) = / 7^ 0. We will show that 
this leads to a contradiction with the hypothesis. Prom Definition 2, 
we have Vn,n' E V5, n G As{n^) => As{n) C As{n'). This together 
with As{ni) 2 As{7i2) implies rii 0 ^^(n2) (symmetrically, we prove 
^2 0 -^5(ni)). Let n/ be a node in I then n/ 7^ ni and n/ 7^ ri 2 . 
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Moreover, n/ G As{ri2) implies there is a path from ri2 to n/ in G5; 
since ri2 0 and there is no path from ri2 to ni, we can then 

conclude that notActivables{ni)^ which is in contradiction with the hy- 
pothesis. □ 

The next proposition states that two activable nodes can never be on 
the same cycle. One important corollary of this is that the graph of 
processes of the parallel program is acyclic. This guarantees deadlock 
freeness. 

Proposition 1 In an interpreter state S, if two nodes n\ and U2 of Vs 
are in a cycle in Gs, then one at most is activable. 

Proof. The node rs is such that it is not accessible from any node 
in Gs] rs is not in the accessibility of any node. Plus, in a given inter- 
preter state, all objects that are not candidates for garbage collection are 
reachable through a path rooted at a local variable so that, according 
to the definition of G5, any node in an accessibility graph is reachable 
from rs- 

Consider two nodes n\ and ri2 in S such that there is a path from ni 
to ri2 and a path from U2 to ni in Gs and a shortest path P from rs 
to ni in Gs- Either P passes through U2 or not. If it does, then the 
subpath of P that ends at ri2 does not contain n\\ otherwise P would 
not be a shortest path from rs to n\. Prom this, we conclude that there 
is a path in Gs from rs to ri2 that does not contain n\ or a path from 
rs to ni that does notcontain U2- In the first case, there is a path from 
’f'S 0 -^5(^1) to ^2 ^ ^5(^1) that does not pass through n\. Prom this 
we can conclude that n\ is not activable. In the second case, we can 
conduct the same reasoning replacing n\ by ri2 and conversely conclude 
that ri2 is not activable. In both cases, one of the two nodes is not 
activable that is, one at most is activable. □ 

Proposition 2 Let n\^n2^ni 7^ U2 be two activable objects in a state S, 
then Ss{ni) n <55(712) = 0 

Proof. Prom Lemma 1, there are three cases to consider: 

(i) As {ni)r\ As {ri2) = 0. Prom Definition 3 we get that for all activable 
object n, <S5(n) C ^4.5(71) and we can conclude that Ss{ni)r\Ss{ri2) = 0- 

(ii) .45(711) C ^45(712) then tii G .45(712) and consequently, 

^s(«i) c y ^5(n') 

n'^As (ri2 ) ^Activables (n' ) 
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Prom this, we conclude that As{ni) fl Ss{ri2) = 0 and finally that 
Ss{ni) r\Ss{n 2 ) = 0 because Ss{ni) C ^ 5 -(ni). 

(iii) As{ri2) Q As{ni). This is the symmetric case of the previous 
one. □ 

The next proposition states that all incoming edges of a non-activable 
node (a passive object) are from nodes in the same subsystem. A con- 
sequence is that a non-activable node can only be reached by nodes of 
its subsystem or through the active node of its own subsystem. 

Proposition 3 In a state S, given a subsystem Ss{ti) such that n is 
activable, Vn' G <? 5 (n), V{n",n') ^ Es, n' n n” E Ss{n) 

Proof. Assume n ^ n' and n" 0 Ss{p). We will show that this leads 
to a contradiction. There are two cases to consider: 

(i) n" 0 As{ti). In that case, because (n",n') G Es^ there is a path 
from a node outside As(p) such that n does not belong to that path. 
This is in contradiction with Activahles{n), 

(ii) n" G As{n), Then, because n" 0 Ss{n)^ and using Definition 3, 
n' is in the subsystem of another node. So, there is a node n'" G Vs such 
that n'" G As{n) and Activablesin!”) and n" G As{n”'). 

Prom this and {n” ^n') G Es^ we get n' G As{n'”). Prom that last 
fact and Definition 3 we get n' 0 Ss{n) which is in contradiction with 
n' G Ss{n), □ 



Definition A In a state S = the graph of subsystems is a graph 

= {Vg^E'^) such that: 

■ Vg = {n E h\Activables{n)} 

■ {n, n') e E'^ <=^3o e Ss{n) A (o, n') G Es 

Propositions 2 and 3 together guarantee that any object in a subsys- 
tem is only accessible from the root of the subsystem. Because active 
objects serve one request at a time, this guarantees that the parallel 
system obtained is race condition free. 

Proposition 1 states that two objects that form a cycle can not be both 
activable. According to Definition 4, this guarantees that the process 
topology is a DAG, and so the resulting parallel system is deadlock- free. 

All this, together with Proposition 1 guarantees that the parallel sys- 
tem obtained by activating activable objects is sane in some sense but it 
is not enough to guarantee that it is equivalent to the sequential system 
in term of results. 
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To guarantee this, we prove a last proposition that states that pro- 
cess graphs are trees. This ensures a stronger form of Bernstein’s con- 
ditions: read/write domains of any two processes are disjoint. 



Proposition 4 The graph of subsystems is a tree. 

Proof. Formally the proposition is expressed as follows: in an inter- 
preter state S let ni, TI2 and by activable nodes then (ni^ns) G E'^ 
and {ri2j ns) E Eg ^ ni = U2. Consider that ni 7^ n2, we will show that 
this leads to a contradiction with Activables{ni) A Activables{n2) A 
Actwahles(ns) . From (ni,n3), (n2,ns) G Eg^ we get that there are two 
nodes oi G Ss{ni) and 02 G Ss{n2) and two edges (01,713) and (02,713) 
in Es- From oi G <55(711) we get that there is a path from ni to oi in Gs 
entirely contained in Ss{ni). Identically, there is a path from U2 to 02 
entirely contained in <55(712). From the last fact, we can conclude that 
^5(^3) Q ^5(^1) and ^5(713) C ^5(712). Now from Lemma 1 we get 
three cases to consider: 

(i) .4.5(711) n .45(712) = 0. This hypothesis is in contradiction with 
^5(^3) C .45(711) and .45(n3) C .45(712). 

(ii) .45(712) Q As{ni). We have .45(713) C .45(712) that is ns G 
^45(712). We also have a path from ni to oi entirely contained in Ss(ni) 
and an edge from oi to ns that is a path from a node that is not in 
-45 (772) (because there is no cycle between two activable nodes) to a 
node that is in 4.5(712) (this node is ns) and that does not pass through 
712- This is in contradiction with Activables{n2)> 

(iii) 45(711) C 45(712). This case is the same as the previous one, 
inverting n\ and 712. □ 

In the case where asynchronous calls performed by a method execution 
are not in a loop, because the topology of processes is a tree, the vari- 
ous parallel activities triggered have disjoint read/write domains. They 
satisfy the Bernstein’s conditions [10]. Actually, they verify a stronger 
version of Bernstein’s conditions where the union of read and write do- 
mains of each process are disjoint. 

Because subsystems are disjoint (Propositions 2 and 3), a subsystem 
and the subsystems that it refers to have disjoint read/ write domains so 
any operation performed by a subsystem and any operation performed 
by a refered subsystem satisfy Bernstein’s condition. 

If an asynchronous call lies in a loop, the successive execution of that 
call may not be independent. Because execution of subsystems is sequen- 
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tial and processes achieve a FIFO service of request^, the successive calls 
are executed one after another, in the order they have been requested 
by the referencing subsystem so that the possible dependence between 
successive executions of a method are respected. 

The activable property as expressed so far is quite restrictive. However 
it is possible to relax it in various ways. First, in the second part of 
Definition 1, we can ignore dead variables because objects they point to 
will not be accessed through those variables. Second, we can allow in 
the sequential side non-mutable objects (Integer, String in the Java 
core classes) to be shared by several subsystems. In the parallel version, 
those shared objects are copied on asynchronous calls so that they are 
not actually shared and because they are not mutable the subsystems 
still verify the Bernstein’s conditions. 

4. STATIC CHECKING OF THE CRITERION 
AND IMPLEMENTATION 



A condition for parallelization and distribution expressed on states of 
an interpreter is useful to understand the model of distribution and to 
guarantee the correctness of program transformations. However it is far 
from being sufficient because it is not possible to directly use it to find 
activable objects in programs because the execution traces of programs 
may be infinite. 

We have designed and implemented a static analysis of Java programs 
that computes an approximated representation of object graphs associ- 
ated to program points. It is written in Java itself. 

This analysis is an inter-procedural extension of the shape analysis 
of Sagiv et al. [33] that applies to an object-oriented language and in- 
cludes abstract garbage collection capabilities (abstract garbage collec- 
tion makes it possible to detect tree/list shape invariants when removing 
operations are performed on such structures). We have also designed a 
test [6] that detects, on the results of this static analysis, instantiation 
points where created instances fulfill the condition for the parallelization 
described in Section 3. 

In the general case, we cannot find all of the instantiation points that 
could be transformed to create active instances because static analy- 
sis only provides an approximated representation of the object graphs. 
However, we get a conservative algorithm that computes a sufficient con- 



^this is the default service policy in ProActive. 




156 





PPro(199Mhz) 


PII (300Mhz) 


Ultra5 (300Mhz) 


Btree 


2,4 


1,6 


1,0 


List 


1,4 


0,9 


0,6 


Sieve 


2,1 


1,5 


0,9 


RecursiveBtree 


6,4 


4,0 


2,3 



Table 1 CPU Time for the analysis (in seconds) 



dition for the condition given in Section 3 to be satisfied. Because we 
have designed the analysis by abstract interpretation [16] of our opera- 
tional semantics of Java programs [6], we can formally relate a test on 
abstract representation of states to the properties we give in Section 3 
through an implication relation. 

On the example from Figure 1, our prototype could detect that all in- 
stantiation sites of the Btree class can be safely turned active, including 
the sites within the method createChildren. 

Shape analysis is a generic name for analysis that aims at statically 
inferring properties on dynamically allocated structures. One trend of 
work in that area consists in using a finite naming scheme for objects 
or equivalently partitioning objects into a finite number of equivalence 
classes. Several analysis algorithms use a finite naming scheme that 
induces a partition of nodes. Identifiers of abstract nodes can be the 
classes of objects. Chase, Wegman and Zadeck [15] use allocation sites 
to further partition the set of concrete nodes. However, properties that 
they can extract from programs are not powerful enough for us to check 
the Property 1. On the other hand, the algorithm of Sagiv et al. is 
powerful enough to precisely represent tree structures and cyclic lists 
among other things. The key features of this static analysis is to use sets 
of referring variables for naming abstract objects and a boolean attribute 
that explicitly represents sharing of objects. These features allow the 
algorithm to precisely represent operations that delete references into the 
heap (operations of the form x . s = y) which no other known method 
can do systematically. 

A few experiments have been conducted on the prototype analyser 
we have developed. The prototype first computes a system of equations 
that represents the program to analyse, and then iteratively solve the 
system of equations. Table 1 summarises the results of a few measures 
we have done on various typical programs, running on a Java Virtual 
Machine with a JIT. 
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Btree is an iterative implementation of binary search trees (with in- 
sertion only). List is an iterative implementation of singly linked lists. 
Sieve is a recursive prime number generator that builds up a singly 
linked list of prime numbers. Finally, RecursiveBtree is the recursive 
implementation of binary search trees as given in Figure 1. 

From those first figures, one can notice (not surprisingly) that recur- 
sive programs are inherently more complex to analyse. 

In addition to those small programs, we conducted some experiments 
on a bigger one (in the range of 550 lines of Java code). The program 
automatically derives and simplifies arithmetic expressions using some 
rewriting rules. It is based on the visitor pattern [20] and is massively 
recursive and polymorphic. As such, it represents some sort of stress test 
for our analysis. We currently manage to analyse it within 10 minutes 
or so, and the memory consumption stays within reasonable values (20 
MB). 

5. RELATED WORK 

The seminal paper of Bernstein [10] introduced the conditions known 
as Bernstein’s conditions for (semi-)automated parallelization. These 
conditions state that two segments of code that have disjoint write do- 
mains and such that the read domain of one is disjoint from the write 
domain of the other one, can be executed concurrently. Then, a trans- 
formed program where these segments are executed concurrently pro- 
duces the same result as the sequential one and terminates if and only 
if the sequential program terminates. 

Number of works use these conditions to establish the correctness of 
automatic parallelization for various languages. Among others, Hendren 
and Nicolau [26] parallelize C programs with dynamically allocated ob- 
jects (with the limitation of no cyclic structures). This work has been 
pursued by Hendren [25], and gave rise to multiple analyses of dynami- 
cally allocated structures and pointers [22, 17, 21] that are the basis of 
a checking algorithm for Bernstein’s conditions. Other authors [24, 28] 
have also investigated the use of shape analysis for the detection of par- 
allelism. These works differ from ours for two main reasons: the par- 
allelization happens at the procedure level, not at the object level and 
distribution issues are not addressed. 

We also have to cite the corpus of work devoted to automatic par- 
allelization of Fortran programs [8, 18, 19] which, in a large part, con- 
sists in the definition of data dependence tests, with the goal of tar- 
geting distributed memory architectures. Detection of parallelism and 
automatic distribution are traditionally two different tasks in compil- 
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ers/parallelizers since data structures, usually arrays of numeric data, 
are not amenable for distribution. In contrast, thanks to the object data 
structure and specific features of ProActive, we can detect parallelism 
and possibility for distribution with the same algorithm. 

Rinard and Diniz [31] present a method for the detection of paral- 
lelism into object-oriented programs. Beside the fact that they do not 
address distribution, the way they detect parallelism is radically differ- 
ent from other works: instead of testing Bernstein’s conditions, they look 
for operations that commute (for instance, associative operations). 

Almeida presented in [2] a type-system that relies on an abstract in- 
terpretation of object-oriented programs as a checking mechanism. This 
type system classifies objects in two categories, standard types and bal- 
loon types where objects of the second type must have a self-contained 
accessibility and must not be shared. With our notion of subsystems, 
we only impose that activable objects have a self-contained accessibility. 

6. CONCLUSION 

This article intends to make some contribution to the automatic dis- 
tribution of object-oriented programs. We presented a criterion for the 
detection of distribution in Java programs: a set of properties that al- 
low to turn standard objects into active objects to be distributed. This 
criterion can be used in the context of ProActive, a Java library for 
distributed, concurrent and parallel programming. 

One contribution of this work can also be stated as it follows: given 
a graph of objects corresponding to a sequential program at execution, 
how can we partition it into a tree-shaped quotient graph that can be 
easily distributed ? To statically achieve such a partitioning, we have 
designed, and implemented in Java a prototype system that analyses 
sequential programs. It is an extension of the shape analysis proposed 
by Sagiv et al. [33]. 

The work presented here has to be extended in various ways. First, 
we want to further investigate the extensions of the criterion, in order 
to provide more flexibility. In particular, we want to find an extended 
criterion that allows the distribution of some programs for which the 
topology of processes forms a DAG instead of a tree. We will also in- 
vestigate the possibility of designing a static analysis, derived from the 
shape analysis of Sagiv et al., that directly finds activable objects instead 
of relying on an algorithm that finds in shape graphs activable objects 
(this is what we currently do). The parametric view of shape analysis 
presented in [32] provides a good starting point for this. 
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Abstract This paper shows how a combination of relational and behavioural se- 
mantics might be used in the creation and verification of object models. 
Specifications written in UML may be expressed in terms of abstract 
data types and processes; different notions of refinement may then be 
used to establish consistency between diagrams, or to verify that a de- 
sign is faithful to the specification. 

Keywords: specification; verification; refinement; consistency; analysis; UML 

1. INTRODUCTION 

The Unified Modeling Language (UML) [19] is a visual language for 
the specification of object-oriented systems. It can be used to describe 
both structure and behaviour at different levels of rigour and abstraction, 
using a variety of graphical notations. As [15] observe, it has a precisely- 
defined syntax and static semantics, but only an informally-specified 
dynamic semantics. 

A considerable amount of work has been done on the formal semantics 
of UML, notably: a type semantics of class models [11]; a dynamic 
semantics for state diagrams [15]; and the combined work of the precise 
UML group [17]. Also important is the work of [2, 1], using LOTOS [14] 
to reason about Use Case Maps [6]. 
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In this paper, we build upon this work using formal description tech- 
niques to reason about UML specifications; we show how individual 
UML diagrams may be used to construct formal descriptions of system 
behaviour in terms of abstract data types and processes. The relational 
and behavioural semantics of these formal descriptions can then be used 
to support the further development and analysis of an object model. 

Our immediate objective is not the definition of an adequate or com- 
plete formal semantics for UML. We are concerned instead with the 
practical issue of how projections of these semantics might be used for 
analysis and verification. We restrict our attention to diagrams and 
class descriptions formulated at a particular level of abstraction: one at 
which the names of methods and navigability of associations have been 
identified. 

We show how a formal representation of a cla^s description can be 
used to verify a proposed implementation against specification diagrams. 
The class description itself can be used to construct a single composite 
abstract data type, whose semantics can be compared with those of the 
individual specification diagrams. 

Once we have constructed our formal descriptions, we are able to 
compare them using notions of refinement for abstract data types and 
processes. Since both static and dynamic information is present, our 
method of comparison requires the definition of a behavioural semantics 
for data types. 

The particular semantics we employ is a blocking semantics, in the 
sense of [5]; operations or methods cannot occur outside their domain 
of definition. This might seem, at first, a surprising choice for object 
modelling, given that the public methods of an individual class are al- 
ways available. However, in examining the behaviour of combinations 
of classes, we observe that in context, methods are not always available, 
either because of synchronisation constraints or because no active ob- 
ject is ready to call them. With a blocking semantics, we can encode 
information about availability within our data types. 

We present two semantic models: one relational^ the other behavioural. 
Each model admits a notion of refinement, and a corresponding proof 
technique. In the relational model, refinement can be established induc- 
tively, using simulation rules [22]. In the behavioural model, refinement 
can be established by model-checking [18]. 

The behavioural semantics, one of those identified in [10], is consistent 
with the relational semantics, in that the two refinement orderings co- 
incide: a data type is refined in the behavioural model precisely when it 
is refined in the relational model [4]. This equivalence allows us to move 
freely between state-based and behavioural views, using whichever mode 
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of description, and whichever proof technique, is the most directly ap- 
plicable. For example, abstract data types are a natural target for class 
descriptions, but sequence diagrams and activity diagrams are more eas- 
ily formalised in terms of processes. 

The paper begins with a brief introduction to the two semantic mod- 
els, and to our notation for data types and processes. In Section 3, we 
describe the construction of a data type based upon a class model, and 
show how the static and dynamic content of various UML diagrams may 
be tested against this description. In Section 4, we discuss the prospects 
for extending this work to a larger subset of UML, examine how the var- 
ious transformations may be automated, and suggest a strategy for the 
verification of implementation-level diagrams and byte code. We assume 
some knowledge of Z [21], and in particular, the schema calculus. 

2. SEMANTICS 

State-based and behavioural specification techniques can be used to- 
gether to create and reason about formal descriptions of object-oriented 
systems. As [5] details, a considerable amount of work has been done in 
linking these two paradigms: notably [13], [9] and [20]. 

2.1. ABSTRACT DATA TYPES 

An abstract data type combines a notion of state with a collection 
of named operations, modelled as relations, that may involve input and 
output. Two of these operations are distinguished, representing initiali- 
sation and finalisation of the data type. 

In modelling data types, we may choose either to associate each op- 
eration with input from, and output to, the context of the data type, or 
alternatively, to maintain the notion of a local environment that stores 
inputs and outputs from initialisation to finalisation. These two ap- 
proaches are equivalent: see [22] and [3]. 

In this paper, we adopt the second approach, defining our data types 
in terms of three generic parameters, representing the internal state 
space, the set of possible operation names, and the local environment. 

— ADT[Local^ Name^ Env] 

state : P Local 

init : Env Local 

op : Name {Local ^ Local) 

final : Local ^ Env 



To ensure the adequacy of the local environment approach, we insist 
that both init and final are total relations. 
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The schema notation of Z, used above in its generic form, can also 
be used to describe the components of the data type. We may use 
schemas to represent the state space as a set of bindings — mappings from 
named identifiers to values — satisfying any specified data type invariant. 
Using the schema calculus, we can define operations as relations on the 
state space without necessarily having to refer to the components of the 
state schema. We can work at the level of schema names, using 0, the 
characteristic binding operator; this allows us to refer to the collection of 
identifiers in a particular schema without introducing a named instance 
of the schema type. State and operation schemas can be factorised using 
logical and relational operators. 

An alternative approach to the description of data types is offered by 
Object-Z [8], an object-oriented extension of Z that includes notions of 
class, instance, inheritance and polymorphism. Both paradigms share 
the same underlying interpretation in terms of data types. 

2.2. RELATIONAL SEMANTICS 

We may give a relational semantics to a data type by considering the 
visible effects of finite sequences of named operations. In our approach, 
the possible effects of a given sequence may be seen as a relation between 
environment states, obtained from the sequential composition of the 
individual operations. 

To record the fact that a sequence of operations might be blocked — 
it might require the performance of an operation outside its domain 
of definition — we augment the environment space with a distinguished 
element _L. To ensure that the possibility of blocking is propagated to 
the end of a sequence, we augment the local state space in the same way, 
and consider totalised versions of the operations. 

If X is a set then we write Xj_ to denote the augmented set X U {±}, 
and if r is a relation with source X we write to denote the totalised 
relation r U ((Xj_ \ domr) x {±}) which maps every state outside the 
domain of r onto _L. For example, if X were the set {a, 6, c} and r were 
the relation {a a,b a}, then the totalised version would be the 
relation {a a, 6 a, c JLh-)«_L}. 

Other totalisations are possible. For example, [22] defines one in which 
every element outside the domain is mapped to every element in the 
augmented state. This leads to a non-blocking semantics in which calling 
an operation outside its domain can leave you in any state. 

Under our chosen totalisation the relational semantics of a data type 
is then given by 
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1 = [Local, Name, Env] ■ ■ 

TZ : ADT[Local, Name, Env] -> {seqName {Env±_ Env±)) 

TZ—{\ ADT[Local, Name, Env] • 

[\p : seq(dom op) • 

init^ ^ run^ p op% final^)) 



where run^ maps any sequence of names to a relation upon the aug- 
mented local state. It describes the effect of calling the named opera- 
tions one after the other and is the sequential composition of the totalised 
relations corresponding to each of the named operations. 

We say that data type A is refined by data type C if, for each sequence 
of named operations, the effect upon C is more deterministic than the 
effect upon A. For any sequence p, the relation TZC p must be a subset 
of the relation TZ A p. When this is the case, we write A Q'ji C. Formally, 

^[Abs, Con, Name, Env] — ■ ^ — 

_ - : ADT[Abs, Name, Env] ^ ADT[Con, Name, Env] 

Vi4 : ADT[Abs, Name, Env]', C : ADT[Con, Name, Env] • 

^ Qn C ^ ^ p \ seq Name • TZ C p QTZAp 



Note that the two data types must have the same interface, that is, the 
same combination of Name and Env that defines the signatures of the 
operations. 

Rather than establishing refinement by means of a generalisation ar- 
gument within the semantics, we can establish it inductively, using a set 
of simulation rules. A sound and complete set of rules for simulation in 
the blocking relational semantics is derived in [4]. 

2.3. PROCESSES 

A process, as defined in [12], is a pattern of communication. We may 
use processes to represent components in terms of their communicating 
behaviour, building up descriptions using the standard operators of the 
CSP language. 

Processes themselves are defined in terms of events: synchronous, 
atomic communications between a process and its environment. Com- 
pound events may be constructed using ‘ - the dot operator. A family 
of compound events is called a channel. Channels may be used to rep- 
resent the paissing of a value between components. 

The atomic process Skip denotes successful termination: the end of 
a pattern of communication. If P is a process and a is an event, then 
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a — > P is a process that is ready to engage in a, and if this event occurs 
it subsequently behaves as P. If P and Q are processes then the process 
P ^ Q first behaves as P and then, if P successfully terminates, behaves 
as Q. 

If P and Q are processes, then P F\ Q represents an internal choice be- 
tween P and Q. This choice is resolved by the process without reference 
to its environment. An internal choice over a set of indexed processes 
{i \ I • P{i)} is written Hi : I • P{i). 

An external choice between two processes, written P □ (J, may be 
infiuenced by the environment. This choice is resolved by the first event 
to occur. An external choice over a set of indexed processes is written 
□ i:/«P(i);if each begins with a diff’erent event, then this is a menu 
of processes for the environment to choose from. 

Processes may be defined by sets of mutually-recursive equations, 
which may be indexed to allow parametrised definitions. Parameters 
may be used to represent aspects of the process state, and may appear 
in guards: we write P & P to denote the process that behaves as P if 
B is true, and can perform no events otherwise. 

If A is a set of events, then the parallel combination P |[ A ]| Q is 
a process in which components P and Q can evolve independently but 
must synchronise upon every occurrence of any event from A. Further- 
more, the combination cannot terminate until both processes are ready 
to do so. We use P ||| Q as a synonym for P |[ 0 ]| Q- 

Finally, if P is a process and A is a set of events, then P \ A is a 
process which behaves as P except that both the requirement to syn- 
chronise upon, and the ability to observe events from the set A, has been 
removed. 



2.4. BEHAVIOURAL SEMANTICS 

Several standard semantic models exist for the process language of 
CSP: see, for example, [18]. For the purposes of this paper we will 
employ the traces model and the stable failures model. 

In the traces model, each process is associated with a set of traces, 
or finite sequences of events. The presence of a trace tr in the semantic 
set of a process indicates that it is possible for that process to engage in 
that sequence of events. 

In the stable failures model, each process is associated with a set of 
failures where a failure is a pair in which the first element is a possible 
trace, and the second is a refusal. The presence of a failure (^r, ref) in 
the semantic set of a process indicates that it is possible for the process 
to engage in the trace tr and then refuse every event from the set ref. 
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Letting S denote the set of all event names and CSP denote the 
syntactic domain of process terms, we may define a pair of semantic 
functions T and which each take a CSP process and return respectively 
the set of all traces and the set of all failures of the given process: 

r : CSP -+> P(seqE) 

JT: C5P-+>P(seqSxPS) 

We may use the stable failures model to give a behavioural semantics 
to a data type by exhibiting a process equivalent: the behavioural seman- 
tics of a data type A is the failures semantics of its process equivalent, 
^{process A). The same approach is taken in [10]. 

The function process, from data types to process terms is given by 

P= [Local, Name, Env] 

process : ADT[Local, Name, Env] -> CSP 

process - 

{\ ADT[Local, Name, Env] • 
let 

P{a) = □ n : dom op | o G dom(op n) • 
op.n 

n a' : state | a a' € (op n) • P{a') 

a 

n e' : Env | a i-> e' G final • final, e' -> Skip 

within 

□ e : Env • 

init.e ^ □ a' : state \ e a' E. init • P{a ') ) 



We observe that there axe three channels of events: init and final which 
take an argument of type Env and op which takes the name of an oper- 
ation. 

Both the traces and the stable failiures models admit refinement or- 
derings, based upon reverse containment: 

-Qr-, ■ CSP CSP 

yP,Q: CSP* 

PQtQ ^ T{Q) c T{P) A 
PQjrQ ^ P{Q) C P{P) 

These two notions of refinement axe consistent, in that Cjr C C 7 -. In 
each case, refinement may be established through a combination of struc- 
tural induction [7], data-independence [16], and exhaustive, mechanical 
model-checking [18]. 
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Crucially, the failures refinement ordering coincides with the refine- 
ment ordering in our relational model. For any data types A and 

^ Qtz B ^ process A process B. 

A proof of this result is presented in [4] . 

3. OBJECT MODELLING 

In object modelling, we may use a variety of tools and techniques, 
such cts cl 2 uss models, use cases, scenarios, activity diagrams, interac- 
tion diagrams, sequence diagrams, and state diagrams, to arrive at a 
suggested class description. 

Prom the class description, we can produce a mathematical model of 
the system in terms of data types. If necessary, we can extend this model 
using additional information from activity diagrams and interaction di- 
agrams, either by extending the data type or by placing a constraint 
process in parallel. 

Using the relational and behavioural semantics of these data types, 
we can verify that the design exhibits the intended behaviour, and check 
that the various parts of the specification are consistent. Using the 
refinement orderings, we can compare our data type description to the 
information content of the various use cases and diagrams. 

3.1. CLASS DESCRIPTIONS 

In this paper, we restrict our attention to class descriptions in which 
all class names, attributes and methods have been identified. In addition, 
we consider only those descriptions in which multiplicity and navigability 
information is expressed directly: that is, without the use of association 
classes. 

Information about the availability and effect of methods can be drawn 
either from model annotations using the Object Constraint Language 
(OCL), or from an accompanying collection of state diagrams. 

We can use state diagrams to provide information about the availabil- 
ity of methods if we regard the transition information as complete: that 
is, a method is available precisely when there is a suitably-labelled tran- 
sition from the current state. This assertion applies only to the subset of 
the class methods, and the projection of the class state, presented in the 
current state diagram. Other diagrams may present information about 
other methods, or about the effects of the same subset of methods upon 
other components of the state. 

To reason about state diagrams in which the transition information 
is intentionally partial^ we might employ a non-blocking relational se- 
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Figure 1 Fragments of a class description 



mantics, with a matching behavioural semantics, in which the result 
of performing an operation outside its domain is left undefined. With 
such a semantics, we may refine the information content of a diagram by 
adding transitions. However, no availability information can be inferred. 

As an example, consider the simple class description presented in Fig- 
ure 1. The class diagram describes a single class with two data members, 
a and 6, of types A and 5, respectively. It also introduces two methods, 
methodA and methodB^ but reveals only that they expect no arguments. 

The accompanying state diagram describes the methods in greater 
detail, presenting information about their availability and their effect 
upon the state. Each of the boxes contains a predicate written in OCL 
describing a constraint upon the combination of values taken by the data 
members of the state. 

Using this information, we may define a simple data type using Z 
schemas to describe class state and methods. 
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After initialisation, the state will satisfy a = b = 0. For either method 
to be called, the state must satisfy a ^ 0; if methodA is to be called, 
then an additional constraint 6 > 0 must also be satisfied; a similar 
condition applies to methodB. If methodA is called, then the resulting 
state, described by values a' and 6', will satisfy a' = a + 6 A 6' = 0; if 
methodB is called, then the resulting state will satisfy 6' = 6 + 1. 

In this example, we have no information about the accessibility of data 
members. We will assume that either member could be accessed, and 
choose an injective finalisation: such a finalisation can be used to export 
any state information to the environment. The data type corresponding 
to this example is as follows 

Example 

ADT[State^ Name^ Env] 

state = State 

init = { Env\ Init • 6 Env t-> 9 State' } 
op = { methodA i-> {Op A • 6 State ^ 6 State ' }, 
methodB i-> { OpB • 9 State i-> 9 State' } } 
final G State Env 



where the local environment Env is any set into which the state can be 
embedded. With a schema to match the relation finals 

Final 

State] Env 

9 Env = final 9 State 



we may define a process equivalent for our data type, and hence obtain 
a behavioural semantics for our class description: 

ClassDesc = 
let 

Proc{State) = 

pre Op A Sz methodA -> D Op A • Proc{9 State') 

□ 

pre OpB & methodB — > □ OpB • Proc{9 State') 

□ 

n Final • &nal.9Env Skip 
within 

n Init • init Proc{9State') 
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3.2. ACTIVITY GRAPHS 

To verify that a class description satisfies the requirements captured 
by other diagrams, we need to construct formal descriptions for these 
diagrams. In this section, we show how this can be done for a particular 
language of activity graphs, corresponding to a strict subset of UML. 

The terms in the language, which we will refer to as activities^ corre- 
spond to the action states of a UML activity graph. The atomic terms 
are expressed purely in terms of methods; by identifying methods with 
events, we may express these activities as CSP processes. We consider 
three distinct types of activities: Act^ TAct and Graph. 

Each element of Act is a basic activity with neither an external start- 
ing point nor an external stopping point. Two of these basic activities 
can be combined either sequentially or in parallel to produce another 
basic activity; we use then and parallel to describe these graphical oper- 
ators. In addition, an activity may be turned into a terminating activity 
using stop. These three cases are illustrated in Figure 2. 



^ Actl ^ 



^ Act2 ^ 



\l/ \l/ 

^ Act3 ^ Act4 ^ ^ Acts j 

Y Y 



Figure 2 Combining simple activities and terminating a simple activity: 
then{Actl^ Act2)j parallel (Act3, ActA) and stop(Actb). 



Terminating activities can be combined with explicit forks, or with 
decision boxes as illustrated in Figure 3. The branches of a decision 
are guarded with Boolean expressions. We may obtain the effect of an 
unguarded decision box by setting the guard to true. In Figure 3 we also 
illustrate how we may attach a starting point to a terminating activity, in 
which case the result is an activity of type Graph and how our diagrams 
can be nested: a complete graph can itself be used as a basic activity 
using include. 

We describe loops within activity graphs by using declare and a Label 
to mark where the loop begins and using use to mark where we return 
back to the beginning of the loop. We show how these operators may 
be used in the example illustrated in Figure 4. 

Assuming suitable definitions of Label and Bool^ our language has the 
following abstract syntax: 

Act ::= atom {{CSP)) \ then {{Act x Act)) \ parallel {{Act x Act)) | 
declare {{Label x Act)) | include {{Graph)) 
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booll ^ ^ 

0>- ^ TActl) 

312 

\l/ 

(^TAct2^ 



bool2 



\1/ \1/ 
(^TAct3 ^ (^TAct4 ^ 




Figure 3 Combining terminating activities: decide {hooll^ 6oo/2, TActl, TAct2) and 
fork(TAct3^ TAct4) and include { start {TAct 5 ) ). 



TAct stop {{Act)) \ fork {{TAct x TAct)) \ 

decide {{Bool x Bool x x TAct)) \ use {{Label)) 

Graph start {{TAct)) 



We may now give a behavioural semantics to the language, defining a 
semantic function S by structural recursion: 



S{atomp) 
S{then (a, 6)) 
S {parallel (a, 6)) 
S{declare (x, a)) 
S{include g) 
S{stop a) 
S{fork (a, h)) 
S{decide (p, g, a, b)) 
S{use x) 
S {start a) 



= P 

= S{a)o,S{b) 

= S{a)\\\S{b) 

= let X = a within a 

= S{g) 

= S(a) 

= «5(«)III<5W 

= (p & a) □ (g &: 6) 
= 

= S{a) 



To see the effect of this function consider the activity graph presented 
in Figure 4. 

This graphical representation corresponds to the following syntactical 
definition: 



start{then{A^ 

declare{X^ 

then{B^ 

then{parallel{C ^ D)^ 

decide{p^ g, use{X)^ stop{E))))))). 

Expressing the processes corresponding to the individual action states in 
terms of the inverse mapping atom"" ^ and applying our semantic function 
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we see that the following process expression describes the behavioural 
semantics of the activity graph. 

atom^ A i 
let 

X = atom^ B % {atom"" C ||| atom^D)i 
{{p Sz X) n (q Sz atom^'E)) 

within 

X 



3.3. ANALYSIS 

In attempting to analyse a UML specification, we must take account 
of the context in which each diagram is presented. For example, it 
may be that a particular activity graph was never intended to convey 
availability information for the methods that appear. The choice of 
the two behavioural models allows us to treat the information obtained 
from a diagram in two different ways; having derived a collection of 
process descriptions, we may compare them using the failures model if 
availability information is present, or the traces model if the availability 
information is incomplete. 

In this section we give examples of three simple UML diagrams and 
suppose that they had been constructed during the development process 
of Example^ as described in Section 3.1. We explain how these fragments 
of the specification might be compared against the data type and process 
corresponding to the final class description. 
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First consider the simple activity graph shown in Figure 5. 
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Figure 5 Activity graph for Example 



The processes corresponding to the given action states may be ex- 
pressed in terms of events corresponding to the given methods on the 
class. Suppose, for instance, that action states corresponded to the fol- 
lowing processes 



atom^P 
atom‘s Q 
atom'^R 
atom'^ S 



methodB -> methodA Skip 

methodB methodB Skip 

methodA -> Skip 
methodB Skip 



then Activity^ the process corresponding to this graph, determined by 
applying the semantic function S to the syntax of the graph, would be 
as follows. 



Activity = methodB — > methodA -> Skip i 

( methodB methodB Skip ||| methodA Skip ) i 
methodB — > Skip 

This activity graph is intended only to illustrate a particular use case 
and so it would be inappropriate to infer availability information; we 
use the traces model to compare Activity with ClassDesc, the process 
representing the class description. 

ClassDesc Cx (init -> Activity) s Stop 

This refinement check tells us that every sequence of methods allowed by 
the activity graph is a possible behaviour of the class description. The 
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use of Stop to end the activity process avoids the unwanted requirement 
that ClassDesc should be able to terminate. 

As a further example, consider the sequence diagram shown in Fig- 
ure 6. In terms of possible behaviours, the information content of this 



:User | :Example 

methods 0 




methodA() 



Figure 6 Sequence diagram for Example 



diagram might be represented by the following process 

Sequence = methodB — > methodA -> methodB Skip 

This is a process that can engage in events methodB^ methodA^ and 
methodB^ in that order, before terminating successfully. 

The question of whether the sequence diagram is consistent with the 
class model and state diagrams of Section 3.1 could be phrased as a 
refinement check in the traces model: 

ClassDesc Qt (init Sequence) g Stop. 

For this to be true, {methodB ^ methodA., methodB) must be a trace of 
ClassDesc. 

Alternatively, if the sequence diagram is intended to express the re- 
quirement that methodA should be possible after a single occurrence 
of methodB., then we might perform a refinement check in the failures 
model: 

(init — > Sequence) e Chaos C/? ClassDesc. 

For such a check, we compose the Sequence process not with Stop., but 
with Chaos, a process that can exhibit any behaviour on the current 
alphabet: no restriction should be placed upon ClassDesc once the spec- 
ified requirement has been met. 

As a final example, we consider a state diagram. Such a diagram may 
present only a part of the transition information for the methods that 
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it describes. If this is the case, or if the availability of these methods 
depends upon state components that are not present, then we cannot 
infer availability information. 

In the absence of this information, we may reason about the effects of 
methods by totalising the operations of a data type before considering 
its semantics, mapping any state outside the domain of definition to 
every possible after state. An equivalent effect could be obtained using 
a non-blocking semantics, provided that each method is guaranteed to 
terminate normally. 



r 






c 






a = 0 






a >= 0 




V 


J 











methodB() 
[a <3] 



Figure 1 State diagram for Example 



If the transition information is complete, and the state components 
considered are enough to characterise the availability of the methods, 
then we may reason using the failures model. As an example, consider 
the state diagram shown in Figure 7; this gives rise to the following data 
type: 



AhsState 

a \ lu 



Ahslnit — 

AbsState^ 

a' = 0 



AbsOpB 

AAbsState 

a > 0 A a < 3 



and a process equivalent, defined by 

Abs = 
let 

Proc AbsState = 
pre AbsOpB Sz 

methods — > FI AbsOpB • Proc{9 AbsState') 

□ 

n AbsFinal • &nal.9Env Skip 
within 

nAbsInit • init Proc{9 AbsState') 
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where the schema AbsFinal describes an embedding of the new state 
into the local environment. 

As the two data types have different interfaces — different sets of named 
operations — we cannot compare them without first hiding the methods 
that are not mentioned in Abs: we may perform the refinement check 

Abs Qjr {ClassDesc \ methodA) 

to confirm that this state diagram is consistent with the class description 
of Section 3.1. 

In reasoning about state diagrams, it may be advantageous to reason 
entirely within the relational semantics. Here also, we hide any com- 
ponents that are not mentioned in the more abstract description: any 
operation that is not hidden is composed with the reflexive transitive 
closure of those that are. 

To see how the refinement above could be established using the rela- 
tional semantics, observe that the effect of hiding operation Op A in data 
type Example is described by the following data type 

Con 

ADT[Local^ Name^ Env] 

state = State 

init = { Env] Init i Op A* • 9 Env i-> 9 State ' } 

op = { methodB { OpB e OpA* • 9 State ^ 9 State' } } 

final = Final 



We may demonstrate a simulation based upon the obvious retrieve rela- 
tion 



Retrieve = AbsState A State 

using the simulation rules presented in [4]. We have only to show that 
V ConState'; AbsState' • Coninit Absinit g Retrieve' 

y AAbsState; AConState • 

{Retrieve A ConOpB AbsOpB A Retrieve') 

A 

{Retrieve A pre AbsOpB => pre ConOpB) 

If these two conditions hold, then we may conclude that the class de- 
scription presented in Section 3.1 is faithful to the state diagram of 
Figure 7. 
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4. DISCUSSION 

In this paper, we have shown how relational and behavioural semantic 
models might be used in the verification of object models. Using abstract 
data types and processes based upon class models and diagrams, we are 
able to check that two different parts of a specification are consistent, or 
to verify that a particular requirement has been satisfied. 

The language of diagrams used is a strict subset of UML, and only 
simple forms have been considered here. In particular, the abstract syn- 
tax for activity diagrams excludes the possibility of swimlanes, cross- 
synchronisation, and joins; these require the definition of an additional 
category of activity — starting activities — and a mapping from synchro- 
nisation bars to internal synchronisation events. 

We have said nothing about the translation of class models with multi- 
ple classes and associations. However, as [11] shows, formal descriptions 
of such models can be constructed by promoting the data types that 
model the individual classes. The process of reasoning about these de- 
scriptions can then be simplified: [22] shows that refinement distributes 
through promotion. 

A considerable amount of work remains to be done, both in the appli- 
cation of relational and behavioural semantics and in the wider context 
of the formalisation of languages such as UML. A particularly promising 
area for research is the mechanical translation of diagrams and the au- 
tomatic verification of static and behavioural properties; it is our hope 
that the work presented in this paper may be useful in that regard. 
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Abstract Due to the pervasiveness of diagrams in human communication and be- 
cause of the increasing availability of graphical notations in Software 
Engineering, the study of diagrammatic notations is at the forefront 
of many research efforts. The expressive power of these kinds of lan- 
guages and notations can be remarkably improved by adding extensibil- 
ity mechanisms. Extensibility, the ability of a notation or a modeling 
language to be extended from its own modeling constructs, is a feature 
that has assumed considerable importance with the appearance of the 
UML (Unified Modeling Language). In this paper, a holistic proposal 
to formally support the evolution of the UML metamodel is presented. 
To attain this aim, an algebraic formalization is provided which leads to 
a seamless formal model of the UML four-layer semantics architecture. 
These two characteristics - being holistic and seamless together with re- 
flection are the most innovative aspects of the research with respect to 
formalizing the UML. In particular, a central role is played by reflection. 
A formal language supporting this feature called Maude is studied and 
put forward as the basis for the formalization of the UML extensibil- 
ity mechanisms. Since Maude is an executable specification language, 
the final set of formal models can also be used as a UML virtual ma- 
chine at the specification level. To illustrate the approach, a UML Class 
Diagram prototype is implemented using the Maude interpreter. The 



* Granted by the CICYT (Science and Technology Joint Committee), Spanish Ministries of 
Education and Industry, research project TIC97-0593-C05-02 MENHIR, OM 
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integration of this Maude prototype with a UML commercial CASE has 
been developed, in Java, and is currently working. 

Keywords: Extension Mechanism, Algebraic Specification, Maude, UML Evolution, 
Metaprogramming. 

1. INTRODUCTION 

Object-Orientation is one of the most prominent approaches in cur- 
rent software development. Within this paradigm, the UML [16, 17] is 
the standard 00 notation adopted by the OMG^ and is becoming an 
unavoidable reference in information systems Analysis and Design. 

The UML graphical notation supports extensibility mechanisms by 
means of three extension mechanisms: Stereotype^ Constraint and Tagged- 
Value. A stereotype represents a subclass of an existing modeling ele- 
ment, such as a message, an operation, a class, a use case, and a data 
type, that may have additional constraints and attributes, that is to 
say, it extends the vocabulary of the UML. A constraint extends the 
semantics of a UML element. A constraint is used to specify conditions 
and propositions that must be fulfilled. The constraint may be written 
in natural language or in a particular constraint language such as OCL 
(Object Constraint Language). The third extension mechanism is the 
tagged value. A tagged value extends the properties of a UML element. 
This allows properties such as attributes in the metamodel and both 
predefined and user-defined tagged values to be attached to a model 
element. 

Although this paper can be read in a self-contained way, it is based 
on the previous formalization of the UML metamodel elements, rela- 
tionships and diagrams [9, 10]. This research aims at obtaining a whole 
proposal to support the UML extension mechanisms by means of an alge- 
braic specification, which is in accordance with the four-layer metamod- 
eling architecture on which the UML definition is based [17]. Therefore, 
the semantic framework provided in this paper faces up to the unpre- 
dictable and changeable nature of the UML, without limiting its ability 
to adapt the UML to the needs of a concrete domain. 

In this paper, we focus on one of the UML diagrams, the Class Di- 
agram (probably the kind of UML diagrams most widely used among 
software practitioners) to illustrate the approach, but this is applica- 
ble to any other UML diagram or model. We consider the UML Class 



^The Object Management Group (OMG) was founded in 1989 by computer companies and 
was formed to create a component-based software marketplace by introducing of standardised 
object software. 
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Diagram within the whole UML notation, in a homogeneous and mod- 
ular way, which makes proving UML inter-model properties possible, in 
addition to those properties related to just one model. 

The rest of the paper is organized as follows: section 2 discusses some 
issues that provide the motivation for our framework . Section 3 intro- 
duces the main properties of Maude and shows examples that are used to 
present our proposal in the following section, section 4, which describes 
a procedure to support the extensibility mechanisms by means of both 
equational and rewriting logic computation. Finally, section 5 presents 
some concluding remarks, lessons learned and an outline of the work to 
be done in the future. 

2. MOTIVATION 

The UML notation has received a great deal of criticism since its ap- 
pearance (some of which have been recognized by its authors), due to the 
absence of a formal definition. Many problems (ambiguity, inconsistency 
and incompleteness) have been identified in its semantics [1, 7, 24]. The 
UML static semantics is described by a semi-formal constraint language, 
the object constraint language (OCL) and the UML dynamic semantics 
is expressed in informal English. The formalization of a graphic nota- 
tion can help to identify and remove these problems and also allows us to 
rigorously verify the system models constructed by that notation. Thus, 
the important goal is to combine the intuitive appeal of visual notations 
with the precision of formal specification languages. 

Concerning extensibility, each extension mechanism implementation 
could show different semantics, resulting in different or ambiguous inter- 
pretations. In this matter, formal methods (FM) can also play an im- 
portant role. The formalization of these mechanisms provides a unique 
interpretation and helps to identify and remove any ambiguity. This 
problem was formerly investigated by the authors, putting forward a set 
of extension mechanisms in this case for the object-oriented specification 
language OASIS [23] for which an OBJ3 formalization was proposed [25]. 

Formal languages based on logic, such as Z or VDM, permit us to 
suitably describe the structure of a system. On the other hand, formal 
languages based on process algebras, such as CSP or LOTOS, allow us to 
appropriately represent behavior of a system. However, these languages 
do not currently include the ability to directly handle extensibility mech- 
anisms or specify metaprogramming applications necessary to formalize 
the extension of the UML metamodel. 




186 



The formal language chosen to implement our proposal is Maude^ , 
a mathematically well-founded language, which is based on equational 
[14] and rewriting [21] logic and in addition is executable. Maude is 
an extension of OBJ3 with a far greater performance. Maude reaches 
an agreement with respect to the structure and the behavior of a sys- 
tem and, unlike other formal specification languages, offers an excellent 
framework to cope with changes in the UML metamodel at modeling 
time. The rewriting logic reflective framework can be exploited to sup- 
port the UML metamodel evolution in a natural way. 

Recently, the formalization of UML has been drawing increasingly con- 
siderable attention from many researchers. The effort of research groups 
has evolved from traditional graphical notations towards the UML no- 
tation. In this sense, one of the most relevant research groups is the 
pUML^ group. Research directly related to this paper, but using the 
formal language Z, has been reported by this group [8, 11]. The primary 
goal of the pUML group is to define precise semantics for the UML nota- 
tion and develop mechanisms that allow developers to rigorously analyze 
the UML models. One of the key difierences between our work and the 
work on formalizing UML in Z by this group is, besides the reflection fea- 
ture, that Maude specifications are directly executable, thus providing 
rapid prototyping. 

Although there is some research effort directed towards formalizing 
particular extension mechanisms [2], none of them have addressed the 
extensibility of the UML within a global framework, as this paper does. 
The most innovative aspects in the UML formalizing approach presented 
in this paper are, in our opinion, firstly the fact of formalizing the UML 
metamodel evolution, and secondly its inclusion into the same formal 
framework as the other three UML architecture layers, thus providing 
a unique modular algebraic specification. Moreover, inasmuch as the 
UML is expected to undergo substantial changes in its semantics in the 
forthcoming years (three versions have emerged in the last four years), 
extensibility may play a pivotal role in this endeavor. Our formalizing 
process is holistic (the whole formal model provides integrated support 
for most of the UML diagrams) and seamless (you can navigate from the 
dynamic semantic aspects at the UML object layer towards the model, 
metamodel and metamodel evolution ones, that is to say, along the UML 
four- layer metamodeling architecture). The holistic approach is pursued 



^ Maude interpreter has been available since January 1999 and it is a more powerful language 
than OBJ3. Currently, Maude is freeware and runs under Linux. 

^The pUML group is made up of international researchers and practitioners who are interested 
in providing a precise and well-defined semantics for UML. 
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for unification purposes, that is to say, this integrated formal framework 
permits the user to detect inconsistencies among different views modeled 
by a UML user. For example, a UML collaboration diagram is equivalent 
to a UML sequence diagram, except that the former focuses on the rela- 
tionship among objects, while the latter emphasizes the time sequence, 
both in an interaction. The Maude executable specification generated 
can also be considered as a formal UML virtual machine, therefore pro- 
viding the possibility for a developer to manipulate and animate the 
UML models. 

3. DEALING WITH RIGOR AND 

METAPROGRAMMING ASPECTS IN 
MAUDE 

In order to help us understand the next section, some basic notions 
regarding the formalism used are presented. Maude evolved from OBJ3, 
so we will briefly describe some of the differences between the underlying 
formalism in OBJ3 and Maude. The Maude features will be illustrated 
with some of the definitions and the algebraic specifications used later 
in Section 4. A detailed description of order-sorted equational logic [14] 
and rewriting logic [21] can also be found in any book related to the 
topic (e.g. [13]). 

Extensibility by reflection (the ability of a logic to be interpreted 
in itself) is exploited in Maude so that the basic functionalities of the 
language Core Maude, are extended by reflection to Pull Maude. Next, 
both aspects of the language will be presented. 

3.1. BASIC ASPECTS: CORE MAUDE 

Maude [4] is a formal specification language that supports both equa- 
tional and rewriting logic computation. Maude is an extension of OBJ3 
which is based on equational logic and provides parameterized program- 
ming, multiple inheritance, and a large-grain programming technique, 
to support the scalability of the specification and appropriately manage 
the complexity of a system. Maude’s equational logic called membership 
equational logic extends OBJ3’s equational logic by supporting member- 
ship axioms^ a generalization of sort constraints in which a term is as- 
serted to have a certain sort if a condition is satisfied. Maude’s functional 
modules are theories in membership equational logic. For example, fig- 
ure 1 shows a functional module, where the abstract syntax of a type in 
UML is described. A type comprises a name, a list of attributes and a 
list of operations. The sort Type, the constructor type and the query op- 
eration typeAttribute are declared in the functional module TYPE {fmod 
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stands for functional module^ in Maude). This last operation takes one 
argument, an element of sort Type, and yields its list of attributes. The 
sorts TypeName^ AttributeList and OperationList are declared, respec- 
tively, in the modules TypeName^ AttributeList OperationList^ which 
are imported by protecting declarations. 

(fmod TYPE is sort Type . 

protecting TYPENAME . *** Importing the module TYPENAME, 
protecting ATTRIBUTELIST . *** the module ATTRIBUTELIST 
protecting OPERATIONLIST . *** and the module OPERATIONLIST 
op type : TypeName AttributeList OperationList -> Type 
op type Attribute : Type -> AttributeList . 
op typeName : Type -> TypeName . 
vax TN : TypeName . var AL : AttributeList . 
var OL : OperationList . 
eq typeAttribute (type (TN, AL, OL)) = AL . 
eq typeName (type (TN, AL, OL)) = TN . 
endfm) 



Figure 1 Algebraic specification of a UML type 

The second kind of module in Maude, system module, is based on 
rewriting logic. For the sake of space, this one is not shown in this 
paper. Core Maude also supports hierarchies of system modules and un- 
parameterized functional modules by using the importation of modules. 
The functional module META-LEVEL implements the reflection. This 
property of rewriting logic allows us to represent any flnitely presented 
rewrite theory R by means of a particular rewriting theory, the univer- 
sal theory U. Rewriting logic is also a good logical framework in which 
other logics can be represented [20], thus endowing Maude with high 
expressive power. 

3.2. ADVANCED ASPECTS: FULL MAUDE 

The basic functionality of the language. Core Maude^ is extended by 
reflection to Full Maude. Full Maude, which is written in Core Maude, 
is a metaprogramming application that includes object oriented modules 
(system modules with some syntactic sugar so as to allow us to specify 
concurrent object oriented systems), parameterized modules, views and 
module expressions in the OBJ style. 

As an example, an extract of an object-oriented module called PER- 
SON is shown in flgure 2. The declaration of a class named Person with 
two attributes called name of sort Qid (quoted identifler) and age of 
sort Machineint (machine integer) is introduced by the key word class. 
The message declarations are introduced by the keyword msg (message 
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changing Age) or msgs if multiple messages with the same arity are de- 
fined. The labeled rewrite rules, which are introduced by the keyword 
rl (rule), specify in a declarative way the behavior associated with the 
messages. For instance, the rule labeled changingAge specifies the be- 
havior of person objects, which may receive messages to change its age. 
The rew (rewrite) command is used to rewrite a term representing a 
configuration of a concurrent object system: when a person called John 
with object identifier (01) 1 receives a message changingAge (1, 15)^ 
value 15 becomes its attribute age. The subsort relationship Machineint 
< Oid is introduced, indicating that machine integers can be viewed 
as object identifiers. All object-oriented modules implicitly include the 
CONFIGURATION piede&ned functional module which defines the ba- 
sic concepts of concurrent object systems. Some of these definitions are 
left unspecified such as the sort Oid, completed and used in the module 
Person. Other examples can be found in Maude’s documentation [4]. 



(omod PERSON is 
protecting QID . 
protecting MACHINE-INT . 
subsort Machineint < Oid . 
class Person | name : Qid, age : Machineint . 
msg changingAge : Oid Machineint -> Msg . 
var 01 : Oid . var QI : Qid . vaxs MI, MI2 : Machineint . 
rl [changingAge] : changingAge (01, MI2) < 01 : Person | 
name : QI, age : MI > => < 01 : Person | name : QI, age : MI2 > . 
endom) 

(rew < 1 : Person [ name : ’John, age : 14 > 

< 2 : Person | name : ’Peter, age : 24 > changingAge (1, 15) .) 

Result Configuration : < 1 : Person | age : 15 , name : ’John > 

< 2 : Person | age : 24 , name : ’Peter > 

Figure 2 Specification in Pull Maude of an object-oriented module named PERSON 



As seen above, Maude like other formal languages is helpful in spec- 
ifying both the structure and the behavior of a system. However, the 
outstanding and distinguishing feature of Maude, on which our proposal 
is based, is reflection. This characteristic has been efficiently imple- 
mented in Maude through its META-LEVEL module, and has a great 
practical interest in Software Engineering, thus providing the possibility 
of building both specifications of concrete models and CASE tools sup- 
porting notation evolution, with rigor and homogeneity based on a solid 
scientific foundation. 
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3.3. TAKING ADVANTAGE OF THE 
REFLECTIVE PROPERTIES 

Rewriting logic is reflective [5]. This means that there is a rewrite 
theory called universal theory U that can represent any rewrite theory 
R (including U itself) as a term i?, any terms t, tl in R as terms t and 
tl, and any pair (R, t) a term (i?, t), in such a way that the following 
equivalence is satisfled: 

R h“ t — y tl U f“ (R, t) — y (R, tl) 

Subsequently, an extract of the signature of U is presented in which 
terms and functional modules are reifled as elements of the data types 
Term and FModule. Figure 3 shows the operators used to represent a 
term of any sort and a functional module. 

fmod META-LEVEL is sort FModule . 
subsort Qid < Term .*** to represent variables 
subsort Term < TermList . 

op { _ } _ : Qid Qid -> Term . *** constants by pairs [constant, sort] 
op - [ _ ] : Qid TermList -> Term . *** operators (operator, subterms) 
op : TermList TermList -> TermList [assoc] . *** list of terms 
op error* : -> Term . 

op fmodJs endfm : Qid ImportList SortDecl 

SubsortDeclSet OpDeclSet VarDeclSet MembAxSet EquationSet -> FModule . 



Figure 8 Operators of the universal theory U to represent terms 



The declaration of subsorting Qid < Term is used for representing 
variables as quoted identiflers. The first operator, { _ } is used to 
represent constants by pairs (constant and sort of the constant), both 
in quoted form. The next operator, - [ - ], denotes the recursive con- 
struction of term out of subterms. The first argument represents the 
top operator in quoted form, and the second argument represents the 
list of subterms. Finally, the operator term concatenation is declared. 
On the other hand, a functional module is metarepresented by means of 
eight elements: a name (sort Qid), a list of imported modules (sort Im- 
portList), a sort declaration (sort SortDecl), a set of subsort declarations 
(sort SubsortDeclSet), a set of operator declarations (sort OpDeclSet), 
a set of variable declarations (sort VarDeclSet), a set of membership 
axioms (MembAxSet), and a set of equations (EquationSet). The de- 
scription of these sorts is omitted here, but it can be found in Maude’s 
documentation [4]. 
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In order to illustrate the meta-representation of a term, the module 
TYPE defined in figure 1 is used. A term of sort TypeName and its 
meta-representation (figure 4) are shown as an example. 



tn = typeName (type ( ’Person, attribute (’Male, ’Bool) attribute 
(’Age, ’Integer,), operation (’Income, parameter (’date, ’Date), ’Integer) ) ) 
tn= ’typeName [ ’type [{ ’’Person } ’Qid , [ 

’attribute [ { ’’Male } ’Qid , { ’’Bool } ’Qid ] , 

’attribute [ { ’’Age } ’Qid , {’’Integer } ’Qid] ] , 

’operation [ { ’’Income } ’Qid, ’parameter [{ ’’date } ’Qid, { ’’Date } ’Qid], { 
’’Integer } ’Qid]]]] 



Figure 4 Term of sort TypeName and metaterm of sort Term 



Maude draws efficiently on reflection which can be exploited in meta- 
programming applications such as the present work proposes. In such 
applications rewrites and reductions at both high level (universal theory 
U) and low level (rewrite theory R) may be necessary. Although all 
rewrites and reductions may be done at high level, we should be aware 
that a single step of rewriting at low level involves many rewriting steps 
at high level. Notice that the terms and the modules including equations, 
operations and constant symbols at the low level are metarepresented at 
the high level (see figure 4). The reduction of a term as the one given in 
said figure (tn) at the high level (tn), leads to describing new equations, 
operations and constant symbols in the universal theory U and a number 
of reductions at the high level. 

In order to increase the efficiency of metalevel computations, descent 
functions such as meta-reduce^ meta-apply and meta-rewrite are defined 
in a metalevel theory M, which is an extension of the universal theory 
U. As an example, a metareduction by using the function meta-reduce 
is shown: 

Maude> (red meta-reduce (TYPE, up(TYPE, tn)) .) 

Result Term : { ’’Person } ’Qid 

where the function meta-reduce takes two arguments: the first argument 
is the meta-representation of the module TYPE obtained by means of 
the constant called TYPE declared in the importation of the module 
META-LEVEL[TYPE] (high level). The second argument is the meta- 
representation of a term tn of sort TypeName (figure 4) included in the 
module TYPE (low level). The meta-representation of the term tn in 
the module TYPE is obtained by means of the up command. 
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4. TOWARDS A HOLISTIC 

FORMALIZATION OF THE UML 

Is it actually feasible to define the semantics for all of the UML no- 
tation and its architecture? According to the pUML group, the answer 
is unknown until semantics for all UML is constructed [19]. In addition, 
we must take into consideration the existing problems, referred to in 
section 2, in relation with the current version of the notation. In spite 
of this situation, many efforts are being made in the direction of offering 
formal models for that, as mentioned in said section. 

We know that trying to formalize a (complex) notation in these cir- 
cumstances is not an easy task, but, in particular, the formal framework 
that we report in this paper, can cope with the current semantics of 
UML, and it also serves as a basis for its future versions. This is due to 
the fact that this framework includes the metametamodel of UML; but 
there is a limitation: we assume that the UML four-layer metamodeling 
architecture (explained below) is conserved. Only in the case that its 
architecture changes, the formal framework should change too. 

Subsequently, three approaches to formalize a graphical notation like 
UML are presented. One of these approaches is chosen and tailored 
to the UML four-layer metamodeling architecture. Finally, the formal 
specification supporting our selection is carried out. 

4.1. CHOOSING A FEASIBLE 

FORMALIZING APPROACH 

Extension mechanisms provide additional information included in the 
UML metamodel, that is, metainformation. If formalizing a graphical 
notation is intended, representing both the metainformation and its evo- 
lution should be taken into account. According to the metainformation 
that can be represented, three approaches are distinguished: 

1 Modeling strategy. The formalization is carried out by means of 
a translational strategy, that is to say, by translating each UML 
modeling element to some formalism element. 

2 Metamodeling strategy. The formalism is used to specify the lan- 
guage metamodel. 

3 Meta-metamodeling strategy. The formalism is used to specify the 
language metamodel and its evolution. 

In the first approach a correspondence between each modeling ele- 
ment in the graphical notation and some particular expressiveness, fea- 
ture or construct in the formal language is established [3, 12]. Each 
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UML diagram corresponds to a formal specification in the formalism. 
For example, if an algebraic language such as Larch, OBJ3 or Maude 
is used, an attribute or an operation of a class can be denoted as an 
operation symbol in the formal language. Therefore, an algebraic spec- 
ification corresponds to a domain model (figure 2 shows an example of 
this approach). 

In this approach, a change in the model leads to a change in the 
formal specification, following a manual or automatic procedure based 
on the correspondence previously obtained. If a new modeling element 
such as a stereotype is included in the graphical notation, some formal 
language mechanisms are used to describe both its syntax and semantics, 
so enriching the formal-informal correspondence. In order to obtain this 
goal, analysts must search for suitable features in the formal language 
that best fit the new element and then modify the formal specification 
[2]. Therefore, the evolution of the metamodel is not formally supported 
in the initial specification. 

In the second approach, the language metamodel is represented by a 
formal specification [8, 9, 15]. In an algebraic framework such as Maude, 
the graphical notation syntax is described by what we call the syntactic 
specifications'^^ incorporating the static semantics by means of equations 
or axioms in the syntactic specifications (figure 1). The graphical nota- 
tion dynamic semantics (for example, specifications representing objects) 
are expressed by semantic specifications^ which use the syntactic spec- 
ifications previously obtained so as to maintain the consistency in the 
system state. In a similar way, the same role is played by the concepts 
of descriptor and instance element used by the pUML group [19]. 

As an example, the metamodeling strategy applied to the UML Class 
Diagrams is shown in figure 5. A particular problem model is initially 
depicted by a UML class diagram from the functional requirements pre- 
viously elicited. Then, this model is transformed and represented in an 
alternative and equivalent way by means of a formal term of the quotient 
term algebra of the syntactic theory signatures, that is to say, the inter- 
pretation of the signature. In turn, the instance of a model corresponds 
to a formal term of the quotient term algebra of the semantics theory 
signatures that can also be represented by a term or by the elements of 
the problem. Terml... Termn, Termm are formal terms of the (syntactic 
or semantic theories) corresponding term algebras or formal interpreta- 



syntactic theory is a module that represents the syntax and static semantics of the UML 
model elements. 

semantic theory is a module that represents the dynamic semantics of the UML model 
elements 
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tion models; ErrorMessage and canonicalTerml... canonicalTermm are 
formal terms of the quotient term algebra, which is the minimal formal 
interpretation model. For instance, in the top part of figure 5, a num- 
ber of different incorrect UML class diagrams are firstly translated to 
the same number of, corresponding, formal terms of the term algebra. 
Then, as all of them are erroneous, they are converted (or reduced, in 
algebraic terminology) to a unique, minimal term with the same seman- 
tics, in this case the term ErrorMessage from the quotient term algebra. 
In the same way, as seen in the bottom part of figure 5, objects and 
relationships among objects can also be dealt with. 

However, in the second approach, if a new graphical notation mod- 
eling element, such as a stereotype, is included in the UML, as seen in 
the previous approach, the analysts must search for some formal lan- 
guage mechanisms to express its syntax and semantics and then modify 
the initial formal specification. Therefore, the evolution of the UML 
metamodel is not formally supported either. 
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The third approach deals with the issue of evolution in its two di- 
mensions (modeling and metamodeling). Two levels are proposed to 
formalize a modeling language. The lower level formally specifies the 
graphical notation syntax and semantics, that is to say, its metamodel. 
This level supports the evolution of the model, in such a way that a class, 
an object or whatever modeling element may be included in the system 
represented by a term (in the same way as the second approach). The 
higher level formally supports the evolution of the language metamodel 
and enables us to establish properties that must be satisfied by this 
metamodel. In this level the modules defined to represent the language 
metamodel are reified as formal terms in such a way that elements such 
as a class, a relationship or a constraint may be included in the meta- 
model, therefore extending the notation. This is the approach chosen in 
our research. 

4.2. SEAMLESS FORMALIZING THE UML 
FOUR-LAYER METAMODEL 
ARCHITECTURE 

UML currently provides lightweight extensibility by means of stereo- 
types, constraints and tagged values. Therefore, a formal language en- 
dowed with enough expressiveness to specify new modeling mechanisms 
at specifying time is required. The key idea in our approach focuses on 
using refiection to represent the evolution of the metamodel. Although 
any formal language endowed with refiection could be used, the Maude 
language shall be employed for the reasons mentioned in previous sec- 
tions. Table 1 shows the correspondence between the UML conceptual 
framework and the formal framework that we propose. 



Table 1 Representing in Maude the four-layer metamodeling architecture of UML 



The UML layer 


Maude formal layer 


Example 


Meta-metamodel 


The module META-LEVEL 


MetaClass, MetaOperation 


Metamodel 


Syntactic and semantic specifications 


Class, Operation 


Model 


Terms (of syntactic specifications) 


Person, Name, Age 


User objects 


Terms (of semantic specifications) 


<John, 14>, <Joy, 34> 



The UML user objects layer allows a particular domain to be de- 
scribed. This layer lies on terms of the semantic specifications. For 
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instance, specific objects such as John and his age, 14, can be repre- 
sented in this layer. 

The UML model layer permits diagrams to be defined in terms of the 
concepts represented in the UML metamodel. Problem domain concepts 
such as person^ name and age can be formally represented by terms of 
syntactic specifications. 

The UML metamodel layer aims at obtaining the conceptual frame- 
work to specify domain models and its evolution, that is to say, the 
syntactic and semantic rules on how to construct correct UML class dia- 
grams belong to the metamodel layer (as an example you can see figure 
1). On the other hand, the application of these UML class diagrams to 
describe concrete systems (for instance the subterm representing a type 
name of a domain model shown in figure 4) belongs to the model layer. 
Transformations of diagrams can be supported by means of equations. 
Thus, semantically equivalent diagrams, which are simpler than the orig- 
inal ones, can be obtained. This layer is represented by the syntactic and 
semantic specifications. Concepts such as class^ attribute^ association^ 
operation are formalized in the syntactic specifications and link^ object 
and value are formalized in the semantic specifications. The UML meta- 
model also contains rules, constraints and model usage aspects which 
can be expressed in Maude. 

Finally, the UML metametamodeling layer (the UML highest abstrac- 
tion level) presents the language for defining the UML metamodel and its 
evolution. An extension of the module META-LEVEL covers the meta- 
metamodeling layer. This allows the UML to be customized and adapted 
to the analyst’s modeling requirements or to the other methodologies de- 
velopment process [6] and to develop UML evolving CASE tools. The 
formalization of this layer also enables us to establish properties that 
must be satisfied by the UML metamodel. Therefore, the formalizing 
approach presented here complies with the UML meta-metamodel layer 
framework 



4.3. FORMALIZATION USED 

As a first step towards applying the metamodel extension process, the 
formalization of a subset of UML will be shown. The abstract syntax of 
an attribute in UML is described. An attribute is represented by means 
of a name and a type. The sort Attribute^ the constructor attribute and 
the query operations typeName and attributeName are defined in the 
functional module ATTRIBUTE (figure 6, belonging to the syntactic 
specification layer in table 1). These operations take one argument, an 
attribute, and yield its name and its type, respectively. 
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(fmod ATTRIBUTE is sort Attribute . 
protecting ATTRIBUTENAME . 
protecting TYPENAME . 

op attribute : AttributeName TypeName -> Attribute . 
op typeName : Attribute -> TypeName . 
op attributeName: Attribute -> AttributeName . 
vax NA : AttributeName . var NT : TypeName . 
eq typeName (attribute (NA, NT)) = NT . 
eq attributeName (attribute (NA, NT)) = NA . 
endfm) 



Figure 6 Algebraic specification of a UML attribute 



The next step is to define an extension of the module META-LEVEL 
to deal with the meta- metamodel UML layer (see table 1). The op- 
erations addSorts^ addOperation, replaceOperation, addVariable^ addE- 
quation and removeEquation are defined to allow the modification of 
functional modules (figure 7). 

A functional module is metarepresented by terms of sort FModule 
(figure 3), included in the predefined META-LEVEL module. With the 
module declaration protecting META-LEVEL[ATTRIBUTE]^ the con- 
stant ATTRIBUTE of sort Module (supersort of Fmodule to metarep- 
resent system modules) is declared, and a new equation making the 
constant ATTRIBUTE equal to the metalevel representation of the user- 
defined module with name ATTRIBUTE previously declared is included 
(figure 6). This constant will be used to extend the meta-representation 
of the module ATTRIBUTE. 

Note that in this section we are focusing on the technical aspects of 
the underlying formal models. The practical use of this research assumes 
that a software tool is available, to hide these ugly equations, operations 
and constants symbols from their users. A prototype of this tool is al- 
ready working [10], which takes UML diagrams edited by Rational Rose 
(in XMI format) and produces their equivalent formal representation, 
and an accompanying process model has also been defined [22]. 

4.4. EXAMPLE OF CHANGEABILITY 
EXTENSION 

In order to gain insight into our approach, an example illustrating 
how to extend the UML Class Diagrams is presented. In particular, a 
new attribute, named changeability, is included in the UML metamodel 
metaclass Attribute. This property specifies whether the value of an 
attribute may be modified after the object has been created. With this 
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(fmod META-LEVEL-EXTENSION is protecting META-LEVEL[ATTRIBUTE] . 

*** Add a set of sorts 

op addSorts : FModule QidSet -> FModule . 

*** Add an operation 

op addOperation : FModule Qid QidList Qid AttrSet -> FModule . 

*** Replace an operation of a module identified by its name (second argument) 
op replaceOperation : FModule Qid Qid QidList Qid AttrSet -> FModule . 

*** Replace an operation from a set of operation declarations 
op repOper : OpDeclSet Qid Qid QidList Qid AttrSet -> OpDeclSet . 

*** Add a variable declaration 
op add Variable : FModule Qid Qid -> FModule . 

*** Add an equation. 

op addEquation : FModule Term Term -> FModule . 

*** Remove an equation 

op removeEquation ; FModule Equation -> FModule . 

*** Remove an equation from a set of equations 
op remEquation : EquationSet Equation -> EquationSet . 
var QS : QidSet . var QSl : QidSet . var QI : Qid . var QIl : Qid . 
var QI2 : Qid . var QI3 : Qid . var QI4 : Qid . var OpName : Qid . 
var IL : ImportList . var SD : SortDecl . var SSDS : SubsortDeclSet . 
var ODS : OpDeclSet . var VDS : VarDeclSet . var MAS : MembAxSet . 
var EqS : EquationSet . var EQ : Equation . var EQl : Equation . 
var TEl : Term . var TE2 : Term var AS : AttrSet . var ASl : AttrSet . 
var QL : QidList . var QLl : QidList 

eq addSorts (fmod QI is IL sorts (QS) . SSDS ODS VDS MAS EqS endfm, QSl) 

= fmod QI is IL sorts(QS ; QSl) . SSDS ODS VDS MAS EqS endfm . 
eq addOperation (fmod QI is IL SD SSDS ODS VDS MAS EqS endfm, 

QIl, QL, QI2, AS) 

= fmod QI is IL SD SSDS ODS op QIl : QL -> QI2 [AS] .VDS MAS EqS endfm . 
eq replaceOperation (fmod QI is IL SD SSDS ODS VDS MAS EqS endfm, 
OpName, QIl, QL, QI2, AS) = fmod QI is IL SD SSDS 
repOper (ODS , OpName, QIl, QL, QI2, AS) VDS MAS EqS endfm . 
eq repOper (op QI3 : QLl -> QI4 [ASl] . ODS, OpName, QIl, QL, QI2, AS) 

= if QI3 == OpName then op QIl : QL -> QI2 [AS] . ODS 

else op QI3 : QLl -> QI4 [ASl] . repOper (ODS, OpName, QIl, QL, QI2, AS) fi . 
eq addVariable (fmod QI is IL SD SSDS ODS VDS MAS EqS endfm, QIl, QI2) 

= fmod QI is IL SD SSDS ODS VDS var QIl : QI2 . MAS EqS endfm . 
eq addEquation (fmod QI is IL SD SSDS ODS VDS MAS EqS endfm, TEl, TE2) = 
fmod QI is IL SD SSDS ODS VDS MAS eq TEl = TE2 . EqS endfm . 
eq removeEquation (fmod QI is IL SD SSDS ODS VDS MAS EqS endfm, EQ) 

= fmod QI is IL SD SSDS ODS VDS MAS remEquation (EqS, EQ) endfm . 
eq remEquation (EQ EqS, EQl) = if EQ == EQl then EqS 
else EQ remEquation (EqS, EQl) fi . 

endfm) 



Figure 1 Extension of the module META-LEVEL 
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aim in mind, the module ATTRIBUTE is modified (figure 8) by means 
of the operations defined above. 



moduleAttribute = addEquation (addEquation ( removeEquation ( removeEquation ( 
addVariable (replaceOperation (addSorts (addOperation ( addOperation 
(ATTRIBUTE, ’changeable, nil, ’Changeability, none) 

, ’frozen, nil, ’Changeability, none) , ’Changeability ) 

, ’attribute, ’attribute ,’AttributeName ’TypeName ’Changeability, ’Attribute, none) 
,’A, ’Changeability) ,eq ’typeName [ ’attribute [ ’NA , ’NT ] ] = ’NT .) 

,eq ’attributeName [ ’attribute [ ’NA , ’NT ] ] = ’NA .) 

, ’typeName [ ’attribute [ ’NA , ’NT , ’A ] ],’NT) 

, ’attributeName [ ’attribute [ ’NA , ’NT ,’A]], ’NA) . 



Figure 8 Modification of the module ATTRIBUTE 

A new sort, Changeability^ representing the new attribute of the meta- 
class Attribute is included in the sort declaration. The domain of the 
operation attribute is modified with a new sort, Changeability^ what leads 
to the modification of the operations typeName and attributeName equa- 
tions. Now, we introduce the range of values for Changeability that are 
represented, respectively, by the constant symbols frozen (the attribute 
value may not be altered after the object is instantiated and its values 
initialized) and changeable (no restriction on modification is imposed). 
These changes are carried out by means of the reduction of the term 
moduleAttribute which yields the meta-representation of the extension 
of the module ATTRIBUTE. The resultant module is shown in figure 9. 



(fmod ATTRIBUTE is sorts Attribute Changeability . 
protecting ATTRIBUTENAME . 
protecting TYPENAME . 

op attribute : AttributeName TypeName Changeability -> Attribute . 

op frozen : -> Changeability . 

op changeable : -> Changeability . 

op typeName : Attribute -> TypeName . 

op attributeName: Attribute -> AttributeName . 

var NA : AttributeName . var NT : TypeName . var A : Changeability . 
eq typeName (attribute (NA, NT, A)) = NT . 
eq attributeName (attribute (NA, NT, A)) = NA . 
endfm) 



Figure 9 The module ATTRIBUTE (obtained from the reduction of the term mod- 
uleAttribute in figure 8) 



The module SYSTEMOBJECTS^ which belongs to the semantic spec- 
ifications in table 1, specifies the population of objects existing in the 
system, and includes, among others, operations to add and remove ob- 
jects, and to modify the values of the object attributes. Therefore, the 
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*** constant representing: modifying an attribute labeled as frozen is not permitted 
op errorFrozen Attribute : -> ObjectList . 

*** modify the value of an attribute 
op changeAttributeValue : TypeList ObjectList Oid AttributeName 
Value -> ObjectList 

*** modify the value (Value) associated to an attribute (AttributeName) of an object 
*** (Oid) from a list of objects (ObjectList) 
op changeObjectList : AttributeList ObjectList Oid AttributeName 
Value -> ObjectList . 

*** modify the value (Value) of an attribute (AttributeName) from the list of values 
*** (ValueList) associated to the attributes of an object (AttributeList) 
op change ValueList : AttributeList AttributeName ValueList Value -> ValueList . 
*** check if an attribute from a list of attributes is changeable 
op isAttribChangeable : AttributeList AttributeName -> Bool . 
var OI : Oid . var Oil : Oid . var TN : TypeName . var NEVL : NE ValueList . 
var VL : ValueList . var TL : TypeList . var AN : AttributeName . 
var ANl : AttributeName . var V : Value . var VI : Value . 
var OL : ObjectList . var ATL : AttributeList . var C : Changeability . 
eq changeAttributeValue (TL, OL, OI, AN, V) = 

if isAttribChangeable (typeAttribRName (objectTypeNameROid (OI, OL), TL), AN) 
then changeObjectList (typeAttribRName (objectTypeNameROid (OI, OL), TL), 

OL, OI, AN, V) 

else errorProzenAttribute fi . 

ceq changeObjectList (ATL, object ( OI , TN , NEVL) OL, Oil, AN, V) = 
object (OI, TN, changeValueList (ATL, AN, NEVL, V)) OL if OI == Oil . 
ceq changeObjectList (ATL, object ( OI, TN, NEVL) OL, Oil, AN, V) = 
object (OI, TN, NEVL) changeObjectList (ATL, OL, Oil, AN, V) if OI =/= Oil . 
ceq changeValueList (attribute (ANl, TN, C) ATL, AN, V VL, VI) = 

VI VL if ANl == AN . 

ceq changeValueList (attribute (ANl, TN, C) ATL, AN, V VL, VI) = 

V ChangeValueList (ATL, AN, VL, VI) if ANl =/= AN . 
ceq isAttribChangeable (attribute (ANl, TN, C) ATL, AN) = true 
if ANl == AN and C == changeable . 
ceq isAttribChangeable (attribute (ANl, TN, C) ATL, AN) = false 
if ANl == AN and C == frozen . 
ceq isAttribChangeable (attribute (ANl, TN, C) ATL, AN) = 
isAttribChangeable (ATL, AN) if ANl =/= AN . 



Figure 10 Definition of errorProzenAttribute and changeAttributeValue operations 




Formally Modeling UML and its Evolution 201 



dynamic semantics of the new feature Changeability should be described 
in the module SYSTEMOBJECTS. To attain this goal, the operation 
changeAttributeValue and the constant operation error Frozen Attribute 
are declared in the module SYSTEMOBJECTS (figure 10). Likewise, 
new equations are included to prevent the modification of an attribute 
value labeled as frozen. The equations declared for the query operations 
typeAttribRName and objectTypeNameROid are not shown. The oper- 
ation typeAttribRName yields the attributes of a type by using a type 
name, and the operation objectTypeNameROid yields the type name of 
an object from an object identifier. For the sake of space, the mod- 
ification of the module SYSTEMOBJECTS from the extension of the 
module META-LEVEL defined in figure 7 is not given. This new mod- 
ule is obtained in the same way as the modified module ATTRIBUTE 
has been (see figure 8). 

4.5. VERIFICATION OF THE EXTENSION 

To make the practical interest of metamodel extension clear, we will 
show how to detect the violation of a UML statement (the meaning of 
the label frozen) concerning the new property introduced, changeability. 
A metareduction by using the meta-representation of the terms tl and 
ol is shown in figure 11. 

tl = type ( ’Company, attribute (’SA, ’Bool, frozen) 
attribute (’Number Employee, ’Integer, changeable) ,nonOperation) 
type ( ’Bank, attribute (’Internet, ’Bool, changeable), nonOperation ) 
type ( ’Person, attribute (’Male, ’Bool, frozen) attribute (’Age, ’Integer, 
changeable), operation (’Income, parameter (’date, ’Date), ’Integer)), 
ol = newObject (object ( 8, ’Person, (true 20)), tl, 
newObject (object ( 7, ’Person, (true 22)), tl, 
newObject (object ( 6, ’Bank, (false)), tl, 
newObject (object ( 5, ’Bank, (false)), tl, 
newObject (object ( 4, ’Company, (true 260)), tl, 
newObject (object ( 3, ’Person, (true 26)), tl, 
newObject (object ( 2, ’Company, (false 1000)), tl, 
newObject (object ( 1, ’Person, (false 25)), tl, nonObject)))))))) . 

(red meta-re duce (moduleSystemObjects, 

changeAttributeValue{tl,oI2/ SAjtrue) ) .) 

Result Term : { ’errorProzenAttribute } ’ObjectList 



Figure 11 Term representing the addition of a set of objects. Meta-reduction of a 
term 

The term tl of sort typeList represents a list of types, Company, Bank, 
and Person. TypeList is a sort declared by importing the parameterized 
module X/5T instantiated with the module TYPE. This module specifies 
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the abstract syntax and semantics of a type in UML (a type comprises a 
name, a list of attributes and a list of operations). For example, the type 
Person has two attributes, male and age^ and one operation, income. 

The term ol of sort ObjectList represents the inclusion of eight ob- 
jects in the modeled system. For instance, the person represented by 
the object with object identifier 8 is male and his age is 20. The 
expression change AttributeValue{tl^ol^ 2 SA^ true) denotes the meta- 
representation of the term change AttributeValue (tl, ol, 2, ^SA, true). 
The reduction of this term, which tries to change the value of the at- 
tribute SA belonging to the object with object identifier 2, violates the 
constraint imposed on the equation declared in figure 10, that is to say, 
an attribute labeled frozen (like the attribute SA) can not be modi- 
fied. Therefore, the metaterm { ’error Frozen Attribute } ’ObjectList is 
obtained as a result of the metareduction. 
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Figure 12 Seamless metametamodel formalization 
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To conclude this section, the metamodeling relationships for the UML 
Class Diagrams case, supported by functional modules, are graphically 
shown in figure 12. The metamodel evolution is specified by an extension 
of the module META-LEVEL that implements the universal theory U. 
The terms and the modules from the lower level (representing elements 
of the UML metamodel) are reified as Maude terms. Likewise, descent 
functions are used to efficiently compute reductions at the metamodel 
level. As a result, both extension of the metamodel and of the model 
are supported in a seamless fashion. In the same way, the lowest layer in 
the UML four-layer metamodeling architecture (the User Object UML 
layer) can also be integrated into the metametamodel formalization. In 
this case, the evolution theories are semantic specifications instead of 
syntactic specifications (see figure 5). For clarity, the internal relation- 
ships between the semantic specifications and the metametamodel level 
are not shown in detail in figure 12. 

5. CONCLUSIONS AND FURTHER WORK 

This paper reports research leading to a formal framework to sup- 
port the UML notation extension mechanisms by means of an algebraic 
formalization. The reflective formal language Maude has been chosen 
to firstly represent both the graphical notation model and metamodel 
and secondly, the meta-metamodel by reifying the theories previously 
obtained. Formalizing the meta-metamodel simplifies the modeling of 
the UML extensibility. 

Due to the size and complexity of the UML and taking into account 
the lack of a precise semantic definition, its formalization is a difficult 
task. For this reason, the existence of a formal framework, as the one 
presented in this paper, may be useful in adding new elements and im- 
proving the present definitions in new versions. The final formal models 
obtained rigorously support the unpredictable and changing nature of 
the UML, but the capacity of the notation to tailor the UML to needs 
for a specific application domain of interest is preserved. 

Since most practitioners apply only a subset of elements of the model- 
ing languages, the current trend in Software Engineering is to use simpler 
and easier languages and methods [18]. This research can also be tai- 
lored to CML (Core Modeling Language) which consists in a subset of 
the UML, including the extension mechanisms. 

As Maude is executable, the final set of models can also be used as 
a UML virtual machine, at the specification level, which is a valuable 
characteristic for practitioners. Maude has lived up to the author’s ex- 
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pectations regarding the advisability of using its reflection feature in 
metaprogramming applications. 

This research has also shown that migrating from OBJ3 to Maude is 
quite easy. Former experience with OBJ3 greatly helped us to under- 
stand the concepts included in Maude and its application to Software 
Engineering problems. In particular, as Full Maude supports parame- 
terised modules, views, and module expressions in the OBJ style, our 
previous research related to formalizing UML Statechart Diagrams and 
Class Diagrams can readily be translated into Maude in order to imme- 
diately apply the results of this paper. 

The incorporation of a user interface that hides the formal aspects of 
the language and a deflned model process, will result in a powerful tool to 
edit, validate, verify and execute functional system requirements. In this 
sense, we have proposed, in conjunction with other researchers, a process 
model based on a combination of rapid and evolutionary prototyping 
[22]. In addition we are now in the process of integrating the formal 
speciflcations with Rational Rose and other commercial modeling tools 
via a standard XMI interface. A Java prototype of this environment 
that combines Maude and Rose is already working. As a continuation of 
this research, we are currently working on extending the formalization 
to OCL. A preliminary version of this extended formal speciflcation is 
already available. By using parameterized programming and reflection, 
we will integrate the specifications into both the model and metamodel 
layer to permit the user to specify constraints on a particular model and 
to extend the UML metamodel in a homogeneous way. 

Our future research will address providing formal guidelines for the 
evolution of the metamodel. A wide range of possibilities have also 
opened up: exploring the proof of properties about the metamodel such 
cts detecting deficiencies or design faults of the metamodel, and support- 
ing rules that describe its appropriate evolution. 
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Abstract Object-based sequential programming has had a major impact on soft- 
ware engineering. However, object-based concurrent programming re- 
mains elusive as an effective programming tool. The class of applications 
that will be implemented on future high-bandwidth networks of proces- 
sors will be significantly more ambitious than the current applications 
(which are mostly involved with transmissions of digital data and im- 
ages), and object-based concurrent programming has the potential to 
simplify designs of such applications. Many of the programming con- 
cepts developed for databases, object-oriented programming and designs 
of reactive systems can be unified into a compact model of concurrent 
programs that can serve as the foundation for designing these future 
applications. 

There axe several key questions in developing a model of concurrent- 
objects for wide-area computing. Foremost among the concerns is the 
difficulty associated with managing concurrent interactions, particularly 
when a multitude of machines interact. This is the main topic of this 
research. Additionally, issues of security and fault- tolerance are central 
to wide-area computing. How can a secure computation be carried out 
if the data and procedure reside at different machines? If a computation 
involves several thousand machines - as would be expected for a compu- 
tation on the world-wide web - is it realistic to allow an unknown party 
to have exclusive access to a resource? That party may crash requiring 
a major roll-back effort. Is it reasonable to queue a caller for access to 
a resource when the resource manager could possibly fail, causing the 
caller to block? In this case, it may be more efficient to reject the call 
if the resource is not readily available. We seek a model that allows us 
to experiment with a variety of questions of this nature. 
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Abstract Inheritance is one of the key features in object-oriented design and analysis. 

It especially supports an incremental development by allowing to stepwise add 
new functionality to an existing system design. 

When using a subclass which is a specialisation of a certain superclass, the ques- 
tion arises which of the superclass’ properties still hold for the subclass. We 
investigate this topic for three behavioural subtyping relations, which formalise 
the subtype - supertype relationship among classes on the basis of process al- 
gebra correctness relations. According to the degree of change allowed by the 
subtyping relations, safety and liveness properties of the superclass are preserved 
up to different extents. 

Keywords: Behavioural subtyping, process algebra, refinement, inheritance. 

1. INTRODUCTION 

Inheritance is the one of the key issues for the success of object-oriented 
analysis and design methods as well as programming languages. The main 
purpose of inheritance is to support the structuring of specifications and code, 
and to allow re-use of already written parts. Inheritance can furthermore be 
applied in the incremental development of large systems, starting with a small 
basic system description on which additional functionality is stepwise added 
until the complete system has been designed. Such a development process 
would start with a superclass, capturing the basic requirements on the system, 
and derive new subclasses by inheritance which stepwise add new features to 
the existing functionality. However, this approach is in general not error-free: 
the addition of new features may interfere with the old ones in an undesired 
way. In the telecommunications area this phenomenon is known as feature in- 
teraction. Inheritance in general does not provide any help in avoiding feature 
interactions; in fact, in many applications of inheritance, as for instance simple 
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code re-use, it is not desired to restrict the changes allowed in the subclass in 
any way (see [13] for a classification of different forms of inheritance). 

A relationship among subclass and superclass which requires the subclass to 
reflect the behaviour of the superclass to a certain degree is subtyping. Sub- 
typing in object-oriented formalisms lifts the usual notion of subtype to the 
level of objects. Subtypes should always fulfil the principle of type substi- 
tutability [19]: any changes in the subtype should be transparent to users of 
the supertype. This is also the requirement that we have on an incremental 
design: any addition of a new feature to a class should keep the old func- 
tionality unchanged. Simple code-reuse often does not fulfil the principle of 
substitutability, and in fact this is most often not even intended. The impor- 
tance of subtyping concepts for object-oriented formalisms is witnessed by an 
increasing concern in this topic: as an example, the new UML version 1.3 [15] 
discusses a special subtyping category for statechart refinement; and Sun’s new 
JINI architecture [18] explicitly builds on a notion of subtype, which fixes the 
correctness of services: any request for a special interface type may be granted 
by returning a subtype. 

Subtyping definitions are usually signature-based, i.e. compare operations 
of sub- and supertype according to their signatures. However, signatures alone 
cannot guarantee substitutability since the semantics of methods may change 
completely while retaining the signature. Behavioural subtyping as introduced 
by for instance [12, 7, 1] overcomes this problem by comparing methods of 
sub- and supertype according to their pre- and postconditions and their preser- 
vation of global constraints on the type. A second, different, approach, which 
we follow in this paper (also with the name behavioural subtyping), is taken by 
directly comparing the dynamic behaviour (ordering of method execution) of 
classes, not their methods in isolation. This approach takes a view on classes 
as being active entities. In concurrent object-oriented languages active objects 
have their own thread of control and often have to obey particular protocols in 
order to behave properly. A number of authors have proposed such behavioural 
subtyping relations [6, 14, 4, 3, 17, 2, 9, 8] for object-oriented formalisms, 
most often based on some process algebra correctness relation. These relations 
sometimes come with an alternative testing characterisation, which formalises 
the degree of substitutability obtained by subtypes. The testing characterisa- 
tions can be used to figure out the appropriate application domain of the par- 
ticular subtyping relation: is it only sufficient for objects with a single client at 
a moment or also correct for shared mutable objects. 

Valid subtyping is so far defined as “obtaining a sufficient degree of substi- 
tutability’’. A different view on correctness of subtypes is taken when instead 
the preservation of properties of supertypes in their subtypes is considered. In 
this paper we will be concerned with this view on behavioural subtyping: we 
will investigate up to which extent properties of a superclass are preserved un- 
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der behavioural subtyping. Properties may for instance be safety requirements 
on the methods of the superclass, or liveness requirements, guaranteeing the 
availability of certain services to clients of the class. Ideally, such properties 
should still hold for subclasses, extending the superclass with additional fea- 
tures. This would allow us to avoid the re-verification of properties on a sub- 
type which have already been proven to hold on the supertype. We will study 
the preservation of safety and liveness properties under three behavioural sub- 
typing relations, two already appearing in [8], the third a new one. 

As it turns out, the class of preserved properties of a particular subtype can 
be seen as a characteristic of the subtyping relation. This, together with the 
testing characterisations of [8], gives a second view on subtyping relations, and 
thus sheds some more light on the question of which subtyping relation is the 
most appropriate one for a given application domain. 

We envisage the following use of subtyping relations in the development 
process: for every class, on which we intend to further add some functionality 
by means of inheritance, we figure out its area of application: class with single 
access or with shared access, and depending on this, the appropriate subtyping 
relation guaranteeing substitutability for the application area can be chosen. 
Afterwards all subclasses derived from this class have to be checked whether 
they are correct with respect to the chosen behavioural subtype. The contribu- 
tion of this paper is to show which properties of the supertype now also hold 
for the subtype. This avoids re- verification of properties for every new subtype 
which is created and thus supports modular reasoning. 

The paper is structured as follows: The next section defines the technical ba- 
sis (labelled transition systems and refinement relations). Section 3 introduces 
behavioural subtyping and gives some examples. The following section then 
starts the discussion on property preservation and Section 5 finally gives the 
results. 



2. DEFINITIONS 

Most of the behavioural subtyping relations focusing on the dynamic be- 
haviour of classes are based on some process algebra correctness relation, like 
failures refinement or bisimulation. The application area for process algebras 
is the description of distributed communicating processes, thus they are a rea- 
sonable choice as a basis for behavioural subtyping for active objects. The 
three relations we consider in this paper are all based on CSP theory [10, 16]. 

We start with the definition of the relevant concepts underlying our sub- 
typing relations and correctness criteria. Labelled transition systems (short 
LTS) are used for describing the behaviour of an object (or more precise: of 
its class), the methods that are called on and by the object and their order of 
execution. We view an LTS as describing the behavioural type of an active 
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object. The semantical basis for the behavioural subtyping relations and the 
correctness checks is the failures model of the process algebra CSP. For this 
the communication events of CSP are identified with method invocations. 

We assume S to be a set of methods, in the following also referred to as actions. 
We furthermore have two special invisible actions', r, i/ 0 S and let Hrv = 
E U {r, i/}. Both actions stand for unobservable entities: the symbol r plays 
the usual role of an internal action of an object, whose execution is under the 
control of the object alone; the symbol u stands for an action which is invisible 
to a particular client of an object, but is not under control of the object alone. 
It may have to be executed together with another client of the object. 

Definition 2.1 A labelled transition system (LTS) is a tuple T = (Q, ->,9o) 
such that 

■ Q is a set of states, 

■ — > C <2 X Sti/ X Q is a transition relation and 

■ qo E Q is the initial state. 

A labelled transition system of an object describes the possible states of an 
object (identified by particular values of its attributes), the transitions between 
states (which methods are enabled in a state and how the state changes with an 
execution of a method) and its initial state. 

We write q f if {q, a, q') E Let a E S*^ be a sequence of actions 
and A C S a set of actions. The projection of a on A, a I A, is the trace where 
all occurrences from events not in A are removed. The alphabet of an LTS T, 
a{T), is the set of actions occurring as labels in the transition relation. 

An LTS describes the behaviour of an object. When we compare two ob- 
jects with respect to their behaviour, we look at the traces they may execute 
(sequences of methods) and their failures (what methods are blocked after a 
particular trace). Traces and failures are derived fi'om transition systems. 

Definition 2.2 Let T = (Q,—^,qo) be a labelled transition system, q,(f E 
<2) € ^Tu ond <7 € S*. 

■ q (f iff there are states qa^qi,... ,qn such that q = qo, qi 

qi+i and q„ = f. 

■ q ^ (f iff there is a trace t E E*j, such that q (f and a = t \.Y,. 

■ The set c>/ traces ofT is 

traces{T) := {a e 'E* \ 3q e Q : qo q} • 

■ A state is stable if no r transitions are possible: q stable iff q 
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The set o/ enabled actions of a state q & Qis 
next{q) ~ {a e Q: q qi] ■, 

its maximal refusals are refusals (q) := S \ next{q) 

■ The set o/ failures ofT is 

failures{T) := {(cr,X) €S*x \ 3q £ Q : qo ^ q ^ 

q stable AX C refusals{q)} . 

Note, that failures always have subset-closed refusal sets. Failure sets only 
record the refusals at stable states since r actions (whose execution is under 
control of the object alone) might lead to states which refuse something differ- 
ent. Refinement relations of CSP relate transition systems with respect to their 
traces and failures. 

Definition 2.3 A labelled transition system I is a trace-refinement of an LTS S 
(denoted S Qj- 1) iff traces(I) C traces(S), it is a failures-refinemeilt (S Qjr I) 
ifffailures(I) C. failures{S). 

Some remark concerning the notation: in CSP, the symbol C is used in a some- 
what unusual direction, since on the left hand side we find the specification, i.e. 
the more nondeterministic system, whereas on the right hand side the more re- 
fined implementation is found. The subtyping relations defined later in the 
paper are all based on refinement, therefore we also use this direction there: 
the subtype will always stand on the right hand side. 

These two refinement relations are the basis for the subtyping relations in- 
troduced in the next section and the correctness criteria defined in Section 4. 
We will not treat divergence (livelocks) in this paper, but it can be easily incor- 
porated into the subtyping relations presented here. 

Besides the two refinement concepts, we will ftuthermore need two opera- 
tors on labelled transition systems: restriction and concealment. Restriction is 
a standard process algebra operator (from CCS), concealment is a form of hid- 
ing, which however just makes some set of actions invisible, but not internal. 

Definition 2.4 Let T = {Q,—^,qo) be a labelled transition system and A C S. 

■ The restriction of A '\nT,T \ A, is defined as {Q, -y', qo) with 

~ {(^) o,q') S —^ \ a ^ A} . 

■ TTie concealment of A in T, T \^A, is defined as (Q, —y', qo) with 

6 -y \ a ^ A} 

u \3a:A»{q,a,<f)G^}. 
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Note that concealment renames actions into i>- not r-actions. The concealed 
actions are afterwards not internal to the object but simply invisible. Thus 
concealment differs from classical hiding in process algebras, which assumes 
that the hidden actions are afterwards under control of the object alone. Hiding 
may usually introduce new non-stable states, whereas concealment does not. 

3. BEHAVIOURAL SUBTYPING RELATIONS 

We start the introduction into subtyping relations with a discussion of three 
examples. For all three examples we give a labelled transition system of a 
superclass describing the basic behaviour of the system (in solid lines) and af- 
terwards look at some possible extension made in a subclass (in dashed lines). 
The initial state of the LTS is marked by a circle. Due to the augmentation 
of the alphabet of the LTS during extension (new methods), traces or failures 
refinement cannot be directly used as a subtyping relation; instead we have to 
find a reasonable way of hiding the new methods during the comparison. 

The first example is from the telecommunication area: the LTS of the super- 
class describes the basic behaviour of a (simplified) telephone interface to a 
single user, starting with offJiook followed by a dial-tone and the dialing of 
a number. Afterwards a response or no-response from the called side follows, 
in case of a response the user of the telephone will talk to someone (and the 
telephone has to transmit this). At all times, the user is free to hang up the 
telephone (onJtook). 

The solid states and arrows in Figure 1 show the LTS of the class for a 
basic telephone interface. This class can be the basis for further extensions 
with different features, as for instance call forwarding, call screening or voice- 
mail. The extension we look at here is concerned with call screening, namely 
the possibility of entering telephone numbers of people from which the user 
does not want to accept calls: the new feature has to be chosen after offJiook 
{screen-call), the number has to be entered {type-number), is again displayed 
and has to be acknowledged in order to be inserted in the list of screened num- 
bers. The new feature is shown in Figure 1 in dashed lines. 

No feature interactions occur in this extension: the telephone company can 
be sure that all users are able to use the old service as before, without noticing 
any difference. The basic requirement for this extension “no new behaviour 
on the old service” is fulfilled* . This is the fundamental requirement for all 
subtyping relations, and can be formalised with the help of the restriction op- 
erator: 



‘Not all kind of features in the telecommunication area have this correctness requirement; a lot of features 
intentionally want to change the old behaviour (e.g. teen-line) and then a feature interaction occurs when 
the old service remains available. 
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Figure 1 Basic telephone service (+ call screening input) 

Definition 3.1 (Weak subtyping) Let U, O be LTS’ and N = a{U)\ a{0). U 
is a weak subtype of O (denoted O U) iff 

O Qt U\^Nand 
OQjrU\^N. 

Weak subtyping compares sub- and superclass by completely neglecting to 
look at the new service. The extension in the above example is a weak subtype 
of the superclass. 

The next example and its extension seems to be of a similar kind but reveals the 
need for a different subtyping relation. Figure 2 shows the transition system of 
a simple till; the customer inserts a card into the till and may then choose to 
stop the interaction or make some withdrawal of money. Then (s)he has to type 
her/his pin (personal identification number); when it is correct, the amount of 
money can be chosen and is delivered, when incorrect, another try can be made 
or the transaction can be stopped. The new feature which is added to the basic 
till is the printing of the balance. Once the card has been inserted, the user 
may choose to print the balance and in this case no pin has to be given (the 
data on the card is sufficient for this). After printing the user may stop the 
transaction or make some withdrawal. The (dashed-line) extension in Figure 2 
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Figure 2 Till (+ balance printing) 

for this additional feature is obviously wrong: the typing of the pin can now be 
circumvented when the printing is chosen first. 

With regard to the above defined subtyping relation, the extended till is a 
valid weak subtype, although the new feature interacts with the old service in 
an undesired way. This leads us to the definition of a second subtyping relation, 
which rules out such undesired extensions: 

Definition 3.2 (Safe subtyping) Let U, O be LTS’ and N = a{U) \ a{0). U 
is a safe subtype of O (denoted O U) iff 

OQtU\N and 
O CjF U\N . 

This relation requires that even if a client uses a new service, no new possi- 
bilities of using the old service arise (condition on traces). Furthermore, like 
before, we require that the old service still works correct. The above extension 
of the simple till is not a safe, only a weak subtype. In this safety critical ap- 
plication, especially in the case, where the interface explicitly informs the user 
about the new service (this is what tills do), weak subtyping is not sufficient. 

A last example shows why we are still not at the end of defining relations. The 
following example is different from the previous ones in that it allows more 
than one client to access the services of the class at one moment. The example, 
given in Figure 3, is the interface to a simple printer, which accepts requests 
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Figure 3 Black-and-white (+ colour) printer 



for printing black-and-white pictures, bw^request (up to a certain amount de- 
pending on its internal store), and successively prints them (print Jbw). 

The new feature to be added is the printing of colour pictures. The (dashed 
line) extension is incorrect in that it might at some times block requests for 
black-and-white prints (after some colour prints have been requested but not 
yet printed). Thus, as soon as another client is additionally using the new fea- 
ture of the interface, users of the old service might indeed notice a difference. 
The extension is however both a weak and a safe subtype. Instead, for shared 
objects the following subtyping relations is necessary to capture the desired 
substitutability: 

Definition 3.3 (Optimal subtyping) Let U, O be LTS’ and N = a{U)\ (x{0). 
U is an optimal subtype of O (denoted O U) iff 

O Er U\N and 
OQj^U\N . 

This definition defines a comparison which additionally involves an inspection 
of the refusals in the new part of the LTS. For the users of the old service, no 
new refusals (corresponding to a blocking of requests) are allowed. A correct 
extension of the printer interface would have to serve the requests for black- 
and-white and colour prints concurrently. 
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Figure 4 Correct extension of printer 



Optimal subtyping is the strongest of the three behavioural subtyping rela- 
tions. 

Proposition 3.1 Let U, O be LTS\ N = a{U) \ a{0). Then 
OQl,U^Onl,Uand 

A correct extension of the printer is shown in Figure 4: the new feature can 
be concurrently executed with the old one. For a client of the black-and-white 
printing feature the same service as before is possible. 

Summarising, we now have three subtyping relations for extension of func- 
tionality: two for classes with single access, the first one guarantees a minimal 
correctness on the old service, the second one also guarantees that the new ser- 
vice cannot be used to achieve new effects on the old features, and the third 
subtyping relation guarantees this also for shared mutable objects. 

For two of the subtyping relations (weak and optimal), corresponding testing 
characterisations can be found in [8]. The definition of safe subtyping is new^. 



subtyping relation with the same name appears in [8], but we prefer to call the relation defined here 
“safe”, since it is safe in the sense of preserving all safety properties. 
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4. PROPERTIES AND INHERITANCE 

The main issue of this paper is the relationship between properties which 
hold for a superclass and for its subtypes. Ideally, subtypes should preserve all 
properties of the superclass. 

In the sequel, we take a CSP-like view on property specification: in CSP 
theory properties are expressed as CSP processes (or directly LTS’) and are 
checked on some specification by a comparison of property and specification 
with respect to their traces (then we speak of a safety property) or their failures 
(a liveness property). A property is therefore a process or an LTS describing 
every allowed behaviour and it is checked whether the behaviour of the imple- 
mentation is a subset of this allowed behaviour: We check whether 

P Er 5 or 
PQj^S 

holds for safety or liveness properties P, respectively, and objects S. Since all 
refinement relations are transitive, we can always make the following deduc- 
tion: 



P Er 5 Er ^ ^ Er ^ or P S i ^ P Oy. i , 

that is, all properties proven for S also hold for some refinement I. 

It would be highly desirable to have a similar reasoning for superclasses and 
their subtypes: prove a property for a superclass and know that it also holds 
for all of its subclasses, which are behavioural subtypes. This is especially 
important for an incremental design, which uses inheritance to subsequently 
add new features to already existing and provably correct superclasses. How- 
ever, before we can find out, which kind of properties are preserved for which 
subtype, we have to make clear what we mean by ”a subclass has the same 
properties”. Again, the usual refinement relations cannot be plainly used here 
since inheritance usually introduces new methods in the subclass (extension 
of functionality). A subclass may have traces over a larger alphabet than the 
superclass and may therefore fail to be a trace or failures refinement of some 
property process of which the superclass was a correct refinement. Neverthe- 
less, the subclass may in a broader sense have the same property. 

We explain this idea on the till example of the last section. The basic till is 
correct with respect to the safety property “money is only delivered when the 
correct pin has been typed in”. Formalised in CSP, the property on the simple 
till can be formulated by a process, whose traces involve all possible orderings 
of actions from S in which every method deliver-money is preceded by an 
action correct-pin (interleaving, | | | , of the correct order with all possible 
orderings of the other actions, CHAOS): 

Prop = correct_pin -> deliver_money -> Prop 
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Figure 5 Correct extension of till 



P = (CHAOS(S\{correct_pin,deliver_money}) | | | Prop) 

The simple till is a trace refinement of such a safety tester process, the wrong 
extension is not. This so far is a first observation on property preservation in 
weak subtypes. Now consider a correct extension (as shown in Figure 5). 

This correct extension is a safe subtype of the basic till and also a trace refine- 
ment of P. Is it now a trace refinement of all processes P, of which the basic till 
is? The answer is no, since we may also use tester processes, which already fix 
orderings between new methods of the subclass, for instance: printJbalance 
always before balance. The basic system trivially fulfils this requirement since 
none of these actions occur. Nevertheless, the property does not hold for the 
extended till, thus we have no property preservation here. 

Hence we have to be more precise about what the subclass is expected to 
preserve, and what it means for a subclass to have the same properties as the 
superclass. What it should preserve are all restrictions formulated on “old” 
methods, i.e. those of the superclass. Any property talking about methods not 
present in the superclass clearly cannot be inherited, although the superclass 
may trivially fulfil it. There are two possibilities of formulating the instead 
needed “preservation on old methods”: we only check the property on traces 
over the old methods or we check it on all traces, but by only looking at old 
methods. We call the former type of preservation “weak” and the more general 
form “strong fulfilment”. The first extension of the till only weakly preserves 
the safety property (as long as the old service is used, usage is safe), the second 
extension also strongly fulfils the safety requirement. 
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Definition 4.1 (Safety) Let P, S be LTS’, P describing some safety property, S 
an arbitrary object, and let A QT, be a set of actions (the “old” methods). 

S weakly fulfils the safety properties of P on A (P S) iff 

traces(S) flA* C traces{P) flA* . 

S strongly fulfils the safety property of P on A (P S) iff 

traces{S) 4- ^ traces{P) 4- A . 

Strong fulfilment guarantees that the restrictions on orderings of actions as 
specified by the safety property P are met in an object S, which possibly has 
more methods than those of A. Similarly fulfilment of liveness properties can 
be defined. 

Definition 4.2 (Liveness) Let P, S be LTS’, P describing some liveness prop- 
erty, S an arbitrary object, and let A QT, be a set of actions (the “old” meth- 
ods). 

S weakly fulfils the liveness properties of P on A (P S) iff 

(a,X) € failures(S) , a € A* 

^ 3 (a, Y) Gfailures(P) such thatX D A = F DA . 

S strongly fulfils the liveness properties of P on A (P S) iff 

(cr,X) € failures(S) 

3 (a', Y) E failures(P) such that a 4 - A = cr' 4 - ^ 
and X n A = y n A . 

The condition on refusal sets guarantees that, with respect to A, the same set 
of actions are blocked. Strong preservation always implies weak preservation. 

Proposition 4.1 Let P, O be LTS’, ACS. 

PQjpO 

PC^O =!^ PQt:rO 

The above question “does subtyping preserve properties” can now be formu- 
lated as: if P Qp/yr Oi and O 2 is a subtype of Oi, does O 2 weakly or strongly 
fulfil property P on a{Oi)l 

5 . RESULTS 

Next we investigate whether our three subtyping relations weakly or strongly 
preserve safety and liveness properties. Afterwards we discuss property preser- 
vation as another characterisation of subtyping relations. 
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5.1. PROPERTY PRESERVATION 

In the following we always assume N = a{U) \ a{0) to be the set of new 
methods, and often omit Af as an index to the subtyping relations. We start 
with the treatment of safety properties. Weak subtypes weakly preserve safety 
properties. 

Theorem 1 Let O, U be LTS’ such that O U and let P be an LTS describ- 
ing a safety property. Then 

P\ZrO=^P U . 

Proof: Assume (i) P^T O, i.e. traces{0) C tracesfP) and (ii) O U\N, 
i.e. in particular traces{U \N) Q traces{0). By definition of \^, we get the 
following: traces{U\^N) = traces{U) no;((9)*. Hence trace 5 ({/) Dq;(0)* C 
traces{P), and thus also traces{U) n a{0)* C traces{P) n a{0)*. □ 

For the simple till and its first extension (a weak subtype), we therefore obtain 
the result that the subclass weakly preserves all safety properties of the simple 
till. As the example has also shown, weak subtyping does not guarantee strong 
preservation of safety properties. But safe and optimal subtyping do: 

Theorem 2 Let O, U be LTS’ such that O U and let P be an LTS describ- 
ing a safety property. Then 

PQtO^P U . 

Proof: Assume (i) P C 7 - O, i.e. traces{0) C traces{P) and (ii) O 
U, i.e. traces{U\^N) C traces{0). By definition of concealment we get 
traces{U\^N) = traces{U) 4- a{0) and hence rrace^( (7) 4- C({0) Q traces{P). 
Since traces{0) = traces{0) 4- (x{0), we get traces{0) 4- oi{0) C traces{P) 4- 
a{0), which all in one gives the desired result. □ 

The analogous result for optimal subtypes is a corollary of the last theorem and 
Proposition 3.1. With respect to safety properties, safe and optimal subtyping 
are thus equally suitable. The second (correct) extension of the simple till is a 
safe subtype and therefore strongly preserves all safety properties. 

Considering liveness properties, we get the following two results. Weak sub- 
typing weakly preserves liveness properties: 

Theorem 3 Let O, U be LTS’ such that O U and let P be an LTS describ- 
ing a liveness property. Then 

P O ^ P u . 

Proof: Assume (i) failures{0) C failures{P) and (ii) O U, i.e. O 
U \ N. By definition of we have 
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failures{U\N) = {(cr,X) | 3 K : (<r, F) G failures{U) , a G a{0)*,X C 
FUA^}. 

The rest follows by a simple application of definitions: 

(cr,X) E failures{U) , a G <y{0)* 

Jj. Definition of 

(a, X U A^) G failuresi U\^N) 

^ O u 

{a, X U A^) G failures{0) 

^ PQ:fO 

{a, XU N) E failures{P) 

and furthermore X fl a{0) = {XU N) C\ a{0) holds. □ 

With a similar kind of reasoning we can prove weak preservation of liveness 
properties for safe subtyping. 

Optimal subtyping also strongly preserves liveness properties: 

Theorem 4 Let O, U be LTS’ such that O U and let P be an LTS describ- 

ing a liveness property. Then 

PQjrO=^P U . 

Proof: Assume (i) failures{0) C failures{P) and (ii) O U, i.e. O 
U N. By the definition of , we have 
failures{U\N) = {{a i a{0),X) \ 3{a, F) G failures{U) A X C YUN}. 
The rest follows again by a simple application of definitions: 

(cr, F) G failures{U) 

J). Definition 

VXC FUiV: (aXoi{0),X) E failures{U N) 

^ O U 

VX C F U A : (cr I a(0), X) G failures{0) 

^ PCjr O 

VX C F U A : (a 4. a{0),X) E failures{P) 

forX = F 

(a 4- oc{0), Y) E failures{P) 

and furthermore F fl a{0) = (F U A) fl a{0) holds. □ 

The table in Figure 6 summarises the results on property preservation for the 
three subtyping relations. 

Coming back to our example: since the second extension of the till is a safe 
subtype, it strongly preserves safety and weakly preserves liveness properties 
of the simple till. It does not strongly preserve liveness, since we now have 
traces after which all of the old methods are blocked. However, as long as the 
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safe subtyping 
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optimal subtyping 
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Figure 6 Inheritance of properties 

old features are used, the same liveness is ensured. Since a client of a till is 
free to choose himself what to do and since no-one else may simultaneously 
use the till, this is sufficient for a correct till. 

5.2. CHARACTERISATION 

Last we address the characterisation of subtyping relations by the properties 
they preserve from supertypes. Since the definitions of restriction/concealment 
and weak/strong preservation have already been quite close, tight connections 
are to be expected. 

Theorem 5 Let O, U be LTS’ such that N = a{U)\ a{0). Then 

■ O U if and only if O U and O U, 

m O Ql, U if and only if O U and O U, 

■ O U if and only ifO U and O U. 

Proof: The direction “=>” in all cases follows directly firom the theorems about 
property preservation (by choosing P = O). 

Direction “4=”; There are four implications to be proven here. 

U^OQtU\N. 

By definition of restriction traces{U = traces{U) n a{0)* and by 
weak preservation of safety traces(f/)na(0)* C traces{0)r\alpha{0)* = 
traces{0). 

O f/=J> O Cr 

By definition of concealment traces{U\N) = traces{U) 4- oc{0) and 
by strong preservation of safety traces{U) i a{0) C traces{0) | 
a{0) = traces{0). 

OE“i?^ U^OQjrU\^N. 

Assume (cr, Y) G failures{U\N), that is, by definition of restriction 
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a € o:(0)* and there exists some (cr,X) E failures{U) such that Y C 
XU By weak preservation of liveness we know that there is also some 
(cr, Y') Efailures{0) such that Xn a (O) = Y'C]a{0). By subset closure 
of refusal sets it suffices to show that Y CY'. Without loss of generality 
we assume that S \q:(C?) C Y' (supertype O refuses all events outside its 
own alphabet anyway and we assume Y' to be maximal with respect to 
those events). Then Y C Y' holds since all events in S \ a{0) are in Y' 
anyway and events from a{0) which are in Y are also in X and therefore 
in Y'. 

O U\^N. 

Assume {p, Y) Efailures{U N), i.e. there is some {a, X) E failures{U) 
such that p = a ce{0) and T C X U A. By strong preservation of live- 
ness, we know that there is also some (a, Y') E failures{0) such that 
X n a{0) = Y' n a{0). We the same argument as in the last item it can 
be shown that Y CY holds which completes the proof. □ 

6. DISCUSSION 

In this paper, we have investigated the preservation of properties under be- 
havioural subtyping. We have considered both safety and liveness properties 
and defined weak and strong preservation with respect to methods of the su- 
perclass. At first sight, it seems that the overhead of defining preservation with 
respect to some set of methods is due to the formalism used, CSP. However, 
the same issues also arise when using for instance temporal logic for the spec- 
ification of safety and liveness properties. The superclass may trivially satisfy 
some formula which talks about methods not present in the superclass, and the 
subclass may then fail to satisfy the same formula. 

The results can now be applied in an incremental design with inheritance: 
check what kind of subtype a subclass is and then deduce what properties of 
the superclass are preserved. We aim at developing syntactic conditions on 
subclasses which help in checking subtyping relationships. 

Furthermore we have shown that the type of preserved properties can be 
seen as another characterisation of the subtyping relations (beside the defini- 
tions and testing characterisations), and may additionally aid in finding the 
most appropriate behavioural subtyping relation for the application under con- 
sideration. 

Related Work. A lot of proposed subtyping relations are based on failures 
and traces of classes [6, 14, 4, 3, 2]. They can be distinguished by the degree of 
substitutability obtained. The relation most often used is extension, originally 
defined as one correctness relation for LOTOS [5]. On the one hand extension 
is different from our subtyping relation since its underlying concept is not re- 
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finement, rather it allows more traces (even on old methods) in the subtype. On 
the other hand, extension, like weak subtyping, is also only sufficient for a sin- 
gle client. For none of the above cited relations the preservation of properties 
under subtyping is discussed. 

The only work we are aware of which discusses behavioural subtyping and 
verification, however, in a somehow different area, is the work of Leavens and 
Weihl [11]. They view classes as defining abstract data types and consequently 
behavioural subtyping compares the methods of sub- and supertype with re- 
spect to their pre- and postconditions. This is a state-based view as opposed 
to the behavioural view on classes which we have taken here. Verification in 
their work is concerned with showing the correctness of implementations with 
respect to abstract specifications of operations via pre- and postconditions. For 
object-oriented programs they propose a verification technique called super- 
type abstraction: prove the soundness of an implementation with respect to 
the supertype specification and conclude the soundness also for all subtypes. 
Similar to our approach this allows to omit the re-verification for every new 
subtype which is created. 
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Abstract The obj ect-oriented specification of concurrent and distributed systems has tended 

to emphasise the aspect of substitutability at the expense of code reuse. A variety 
of constraints has been imposed in order to guarantee substitutability in one form 
or another. This paper argues that the incremental development of software spec- 
ifications needs to consider substitutability in the context of code reuse. Further, 
the common approach of starting with an abstract specification and then progres- 
sively refining it (in some general way) means that many existing substitutability 
constraints are too strong. In the context of Coloured Petri Nets, we advocate the 
use of three specific forms of refinement — type refinement, subnet refinement, 
and node refinement. These have weaker demands for substitutability, namely 
that every (complete) refined behaviour has a corresponding abstract behaviour, 
but not necessarily vice versa. An examination of case studies in the literature 
suggests that this approach is applicable in practice. 

Keywords: Incremental development, behavioural substitutability, subtyping, Petri Nets, re- 

finement, concurrency. 

1. INTRODUCTION 

The development of formal methods for object-oriented concurrent and dis- 
tributed systems has emphasised the distinction between subclassing and sub- 
typing. According to Lalonde and Pugh [16] subclassing is concerned with 
code reuse, while subtyping is concerned with substitutability, as formulated 
by Wegner and Zdonik [22]. Note that by code reuse we mean the support for 
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incremental change which is made possible by object-orientation, and not just 
the use of some code in another context without modification. Many proposals 
are primarily concerned with subtyping, while subclassing is a secondary con- 
sideration [1, 2, 4, 20]. No doubt this preference for subtyping is motivated by 
the desire to provide suitable properties which can be used in the construction 
and analysis of systems, while unconstrained subclassing (as in Smalltalk for 
example [9]) is considered to be of minimal use. 

We argue that the above dichotomy is exaggerated. We observe that a primary 
motivation for object-orientation has always been code reuse, which does not 
necessarily imply a complete lack of substitutability properties, as is demon- 
strated by the use of assertions in Eiffel [18]. Our particular interest is in the 
support for incremental development of system specifications. Here, the de- 
signer tends to start with an abstract view of the system, and progressively 
refines that specification to add more detail. The very use of abstraction means 
that the designer has captured some aspects of the system (which will persist 
henceforth) while consciously deciding to ignore others (at least for the time be- 
ing). In producing a refined version, existing behaviour is maintained (in some 
sense), while new behaviour is added. (The maintenance of existing behaviour 
is an important aid to understanding the system, and can also be used for im- 
proving analysis algorithms.) It is appropriate to use inheritance in this context, 
so that the refined version of a system component is derived from the abstract 
version. The designer does not face a stark choice between subclassing and 
subtyping. Rather, code is being reused and some level of behavioural compat- 
ibility is being maintained. This is also the case when an existing specification 
needs to be modified, such as with the evolution of protocol specifications [14]. 
Wegner and Zdoniks comments are particularly pertinent here: 

... the requirements for substitutability and the associated notion of subtype and 
behavioural compatibility is too strong in many practical situations. . . . template 
modification (which is at the heart of subclassing) is more powerful than subtyping 
as an incremental modification mechanism but also less tractable [22]. 

Our proposals for incremental development are presented in the formalism of 
Coloured Petri Nets (CPNs) which capture both state and behaviour. In contrast 
to elementary Petri Nets, CPNs use colour sets to achieve more succinct speci- 
fications, which is particularly important for larger systems. We identify three 
forms of refinement which we call type refinement, subnet refinement and node 
refinement. The constraints we impose on these forms of refinement guarantee 
behavioural compatibility between refined and abstract systems. Specifically, 
every (complete) action sequence of the refined system corresponds to an action 
sequence of the abstract system, and every reachable state of the refined system 
(following a complete action sequence) corresponds to a state of the abstract 
system. The correspondence is achieved by either ignoring the refined action 
or state components, or projecting them onto abstract components. 
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In this work, our primary motivation is to support the incremental develop- 
ment of system specifications. We are particularly concerned that our proposals 
should be applicable in practice. This paper informally presents the three forms 
of refinement in §2 by means of an example. It considers related approaches 
from the literature in §3, and assesses the applicability of our proposals by 
examining some case studies in §4. The formal definitions are found in an ab- 
breviated form in §5 (cf. the more extended presentation with proofs of relevant 
properties in [13]). The conclusions and suggestions for further work are found 
in §6. 



2. BEHAVIOUR REFINEMENT FOR PETRI NETS 

This section presents proposals for the refinement of specifications in the 
Petri Net formalism, and specifically Coloured Petri Nets (CPNs) [10]. The 
proposals are illustrated with a simple example of a library loans system which 
is adapted from [6]. 

In a CPN, state components are called places and are drawn as circles or 
ovals. Places may contain tokens, which consist of values of a particular type 
(the colour set of the place). State changes are called transitions and are drawn 
as squares, rectangles or bars. The arcs connecting places to transitions and 
vice versa indicate how transitions affect the state, their direction indicating the 
direction of token flow. Thus, input arcs indicate the consumption of tokens, 
while output arcs indicate the generation of tokens. The arcs may be annotated 
with the particular tokens which need to be transferred. The transition firing 
modes will determine the particular values of these annotations. 

In our library example, a book will have some associated information, such as 
the author(s), title, publisher, etc. In a CPN, each book can be represented by a 
token, and this information can be captured in the token type called Book. Each 
book will be in one of several states such as available, on loan, and overdue. 
These states can be represented by places in the Petri Net, with the presence of 
a book token in a place indicating that tfie book is currently in that state. Thus 
a CPN for the library books could be as in fig. 1. 

Not all the details of the net have been shown in the diagram. Thus, the 
colour for the token type is not indicated in full, nor is the relation between the 
transition firing modes and the variables inscribing the arcs. Clearly, however, 
the firing mode for transition Borrow will include sufficient information to 
identify the book b and the user u. 

A borrower or user of the library will have some associated information, such 
as their name, contact details, classification of membership, etc. Again, each 
user can be represented by a token type called User, and the various states of 
the user can be indicated by places. In this case, it is convenient to have only 
one place to indicate the state of the user with transitions indicating the possible 
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Available 




expires 



Colours: 

C(Available) = Book 
C(On loan) = Book x User 
C(Overdue) = Book x User 

C(Borrow) = Book x User 
C(Return) = Book x User 
C(Loan expires) = Book x User 
C(Pay fine) = Book x User 



Figure 1 CPN Books — the lifecycle of library books 



Idle 




Borrow Return Pay 

fine 



Colours: 

C(ldle) = User 

C(Borrow) = User x Limit 
C(Return) = User x Limit 
C(Pay fine) = User x Limit 



Figure 2 CPN Books — the lifecycle of library users 



actions such as borrowing or returning a book and paying a fine. Thus, a CPN 
for the library users could be as shown in fig. 2. 

The above two CPNs could be combined into a composite system by fusing 
the similarly-named transitions in the two nets. Clearly, more details could be 
specified, but the example above will be adequate for our purposes of illustrating 
the forms of refinement which we wish to support. 

The first and simplest form of refinement, which we call type refinement, is 
to incorporate additional information in the net in the tokens and firing modes. 
However, each value of the refined type can be projected onto a value of the 
abstract type. For example, it may be desirable to introduce a further classi- 
fication of books to vary the loan period. As far as the subnet for the books 
is concerned, this will simply involve extending the token type for the places, 
and extending the corresponding type(s) for the transition firing modes. The 
changes will affect the firing of the Loan expires transition, especially in the 
composite system. It will certainly be the case, however, that if there is a be- 
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Reserve 

Additional Coiours: 

C(Reservation status) = Book x User 
C(Reserve) = Book x User 



Figure 3 CPN Books — the library books lifecycle refined to include reservations 



haviour of the refined system (i.e. a sequence of transition occurrences), then 
there will be a corresponding behaviour of the abstract system (obtained in this 
case by projection). This is the generic behavioural constraint which we require 
for acceptable refinements. 

The second form of refinement, which we call subnet refinement, is to aug- 
ment a subnet with additional places, transitions and arcs. (We also classify 
as subnet refinement the extension of a token type or mode type to include 
extra values which are independent of previous processing. Here, these values 
of the extended type are not projected onto values of the abstract type but are 
ignored in the abstraction.) For example, it may be appropriate to cater for the 
reservation of books. In this case, we would add a place to hold the reservation 
status for each book, and the transition Borrow would only fire if there were a 
compatible reservation status on the book for the given user. (We use the value 
(b,-) to indicate that no-one has a reservation for book b, and the value (b,u) 
to indicate that user u has a reservation on book b.) The modified part of the 
Books subnet is given in fig. 3. Again we satisfy the constraint that if there is 
a refined behaviour, then there is a corresponding abstract behaviour (obtained 
in this case by restriction), but not necessarily vice versa. 

The third form of refinement, which we call node refinement, is to replace 
a place (or transition) by a place (or transition) bordered subnet. In this paper, 
we advocate the use of canonical forms of such refinements. The basis for a 
canonical place refinement is given in fig. 4. 

It has separate input and output border places — in this case there are two 
of each. Each input (output) border place may have more than one incident 
input (output) arc from (to) the environment. Each input border place has an 
associated accept transition which will transfer tokens from the border place 
to an internal place, here called buf. Similarly, each output border place has 
an associated offer transition which will transfer tokens from place buf to the 
output border place. All the border places and the place buf have the same token 




Figure 4 Canonical place refinement 



type, which is also the mode type shared by the accept and offer transitions. 
None of these transitions has a guard to constrain the flow of tokens. Clearly, 
the abstract marking of such a canonical place refinement is given by the sum 
of tokens in the border places and the internal place buf. 

An arbitrary place refinement will be of the form of the basis of a canonical 
refinement (as above) augmented by subnet refinement which extends the accept 
and offer transitions. 

In our running example, such an incremental change might be the identifi- 
cation of the details of processing a book once it has been returned. In other 
words, the place Available might be replaced by a subnet which takes into ac- 
count the delay in reshelving a book, the possibility of repairs, etc. The node 
refinement for this place is shown in fig. 5. 

Note that this has one input border place called Returned and one output 
border place called On shelves. The Accept and Offer transitions, together with 
the internal place Buf constitute the basis of the canonical place refinement. 
Further activity is achieved by the subnet refinement which extends transitions 
Accept and Offer. (Note that all component places and transitions have the same 
token/mode type, i.e. Book, which is that of the original place Available.) The 
subnet refinement retains the identity of the books, and hence this information 
determines the abstract marking of the subnet. Thus, the place Buf is redundant, 
since its marking is equivalent to the sum of markings of places For checking. 
Under repair. Irredeemable, For shelving. (In our experience, the place Buf is 
commonly redundant in such place refinements.) Further, this abstract marking 
is not modified by the various actions internal to the subnet. Clearly, a refined 
behaviour of the net will have a corresponding abstract behaviour, though the 
reverse will not necessarily be the case. For example, it may be that a book is 
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Figure 5 Subnet indicating the processing of returned books 



damaged to such an extent that its return to the shelves would be indefinitely 
delayed, in which case further borrowing of that book would be disallowed. 

For transition refinement, the canonical basis is given in fig. 6. It has separate 
input and output border transitions — in this case there are two of each. Each 
input (output) border transition may have more than one incident input (output) 
arc from (to) the environment. Each input border transition has an associated 
place reed, which receives a token equal to the abstract firing mode, when the 
input border transition has fired with that mode. The transition switch can fire 
when all the input border transitions have fired (with the matching abstract firing 
mode), thereby completing the input phase. It removes the matching tokens 
from the reed places and puts corresponding tokens into all the send places. 
There is one such send place associated with each output border transition. 
Once such a token is available, the output border transition can fire (with the 
same abstract firing mode). Initially, all the reed and send places are empty. 
The abstract firing of the transition refinement commences with the firing of 
any of the input border transitions and is completed when all the matching 
output border transitions have fired and the reed and send places are again 
empty. Only such complete firing sequences will have corresponding abstract 
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Figure 6 Canonical transition refinement 



\ 




Figure 7 Refined Borrow transition 



firing sequences with matching abstract states. The canonical construction 
ensures that input border transitions fire before the corresponding output border 
transitions, ensuring the enabling of the corresponding abstract transition. 

An arbitrary transition refinement will be of the form of a canonical refine- 
ment (as above) together with a subnet refinement which augments the border 
transitions. In our running example, we may wish to refine the Borrow tran- 
sition to reflect the component activities of checking the student identity and 
processing the book. This might be achieved in the subnet of fig. 7. 

All the component places and transitions have the same token/mode type, i.e. 
Book X User, which is the mode type of the original Borrow transition. (While 
this happens to be the case in this particular example, it is not necessarily so.) 
Note that the transition validate user may fail to fire (because the user is not ac- 
ceptable). In this case, the abstract firing of this subnet will never complete, and 
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hence such an incomplete refined activity will have no corresponding abstract 
activity with matching abstract state. 

Even though the above three forms of refinement can be clearly identified and 
analysed in isolation, they will commonly be used in combination in practical 
applications. 

The above proposals differ from those typically found in the context of High- 
Level Petri Nets (such as CPNs [10]). There, abstraction is used to aid the 
process of developing a Petri Net model, with the abstraction subsequently 
being discarded when the model is simulated or analysed [21]. Thus CPNs, 
as formalised by Jensen [10] and implemented in the Design/CPN tool [11], 
provide substitution transitions for building Hierarchical Coloured Petri Nets 
(HCPNs). Substitution transitions are like macros or textual substitution — they 
maintain structural compatibility, but there is no concept of abstract behaviour. 
The semantics of the construct are defined in terms of textual (or graphical) 
substitution. This means that even if the designer has in mind a notion of 
abstract firing, there is no way to capture this formally in the model, either as 
an aid to understanding or as a hint to improve analysis. 

Our proposals are therefore more constrained than substitution transitions, 
since refinements must satisfy certain properties. This has the advantage of 
ensuring that refinements are behaviourally consistent with the abstractions. 
This is valuable for understanding a hierarchical model and also has benefits for 
analysis. Current indications are that these forms of refinement are applicable 
in practice for the incremental development of system specifications (see §4). 

3. RELATED APPROACHES 

The proposals of §2 require behavioural compatibility between abstraction 
and refinement, but not the strong substitutability of other approaches. Some 
of these approaches are considered in this section and compared with our own 
proposals, with particular emphasis on their relevance for incremental specifi- 
cation. 

Nierstrasz proposes a form of substitutability called request substitutability 
preorder [20]. This is motivated by the notion of active objects providing a 
service to their environment. A service is determined by the service requests 
which can be satisfied and hence the name of the preorder. One object is 
substitutable for another if it supports the same service. Nierstrasz observes 
that the possible traces indicate the acceptable sequences of requests, but not 
the sequences that are necessarily acceptable, and hence the notion of failures 
is adopted. Thus the traces of the refined system must include the traces of the 
original, and if a trace of the original system is performed by the refined system, 
then its possible failures must be a subset of the corresponding failures of the 
original. 
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The motivation for this approach is clearly that of substitutability — a server 
is replaced by another offering the same service. It is not concerned with reuse 
of specifications or the development of a server specification, where an abstract 
view may support a sequence of requests, but where a refined view may only 
accept that sequence if additional conditions are satisfied, perhaps with addi- 
tional service parameters. It is worth noting that since failures equivalence is 
undecidable, Nierstrasz proposes that services be restricted to those that can be 
specified by a finite state protocol. While our proposals do allow the introduc- 
tion of a deadlock in a refinement, nevertheless the conditions for behavioural 
compatibility can be statically checked (see §5). 

Bowman et al [4] consider behavioural subtyping in LOTOS. They are dis- 
satisfied with the above proposal of Nierstrasz because they wish to maintain 
compatible behaviour even when the environment attempts to make a request 
which is not part of the agreed service. In such a situation, the original server 
would deadlock, and this behaviour would be expected of a compatible substi- 
tute. Such behavioural compatibility is satisfied by reduction — one system 
reduces another if it has a subset of traces and if, after a matching trace, it has 
a subset of refusals. The problem with this is that it does not allow the refined 
system to include additional methods, as is common in subclassing in object- 
oriented languages. To counter this, they introduce the notion of undefined 
behaviour which corresponds to calling an undefined method in a sequential 
system. In the context of LOTOS, undefined behaviour is a version of chaos 
which can accept or refuse any request. Now, the addition of a method in 
a refinement will result in defined rather than undefined behaviour (as in the 
original). Thus, the refinement represents a reduction of the original, thus 
maintaining the desired properties (identified above). 

This approach has the strange result of saying that the process i; a; stop [ ] b; 
c; stop can be refined by a; stop [] c; stop and by a; stop [] b; a; stop. Clearly, 
the internal action i can be taken, thus committing the system to perform a; stop. 
In our proposal, the refined system could insist on taking this option, but then 
the other alternative b; c; stop would not be available, and certainly would not 
be available as c; stop or b; a; stop. 

One of the motivations for the above approach is claimed to be incremental 
system development, but it is unclear how this is achieved since the only concern 
seems to be a strongly constrained form of substitutability. The specific example 
cited is that of a trader in the context of CORBA, TINA or ODP. The trader 
identifies a server which will respond to the desired requests, and as long as this 
functionality is supported, additional functionality may be present in the chosen 
server. In this context, it is not clear why Nierstrasz’ proposal is inadequate, 
i.e. why the refinement of the server should also reject requests which cannot 
be handled by the original service specification. 
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Another approach, which is applied in the context of workflow modelling is 
that of van der Aalst and Hasten [1]. Here, the refined system can add meth- 
ods and is required to be bisimilar with the original, provided that the added 
methods are either blocked or hidden. The implication of this approach is that 
the occurrence of additional methods voids any requirements on behaviour. 
Thus, there is a strong requirement of consistency provided the new methods 
are hidden in some way, but no requirement of consistency if the new methods 
are visible. The latter seems to be too unconstrained for incremental develop- 
ment. Note that this approach corresponds to the provision of subnet refinement 
(in our terminology) but does not even cater for type refinement, where addi- 
tional methods may be refined versions of existing ones. This would require 
relabelling, as in the following proposal. 

Balzarotti et al [2] present a range of choices for the semantics of inheri- 
tance. They generalise earlier proposals with the possibility of renaming meth- 
ods. This allows a refinement to support the methods of the original but under 
a different name. This is a useful feature, but is not general enough to sup- 
port our notion of type refinement, since the relabelling is given by a bijective 
function (and not simply suijective). The strongest preorder is called strong 
substitutability which is the protocol inheritance of van der Aalst and Hasten 
(where additional methods are blocked and bisimilarity is required of the re- 
sult). Two weaker forms of preorder are strong substitutability with renaming 
(i.e. the above approach with the possibility of renaming methods) and weak 
substitutability (which is the general form of lifecycle inheritance proposed by 
van der Aalst and Hasten, where added methods may be blocked or hidden). 
Weaker than both of these is the form of preorder called weak substitutability 
with renaming, which is derived in the obvious way. The above preorders are 
all based on action observability and are considered appropriate for subtyping. 
By contrast, they propose an ST-preorder based on the observability of states, 
which is considered appropriate for reuse of specifications. This has a more 
flexible renaming of states (than for actions) since there is an injective map from 
the OLST algebra of the abstraction into the refinement. However, this is still 
not as general as required by our proposal for type refinement where multiple 
refined states may map onto a single abstract state. 

In other words, they acknowledge the difference between substitutability and 
code reuse, but provide different criteria for each. As usual, substitutability is 
not associated with code reuse nor with inheritance. 

In summary, the above approaches support our contention that the emphasis 
of the study of relations between concurrent systems has been on substitutability 
rather than on code reuse, and therefore they have not been particularly suited 
to incremental development. 
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4. CASE STUDIES OF REFINEMENT 

In this section we examine a number of case studies to assess the applicability 
our proposals. The case studies do not necessarily use an object oriented for- 
malism, but the methodology applied does involve abstraction and incremental 
development. Note that some are formulated using the Design/CPN tool [11] 
which supports substitution transitions as a means of abstraction but without 
behavioural constraints. 

4.1. DESIGNING AND VERIFYING A 

COMMUNICATIONS GATEWAY USING CPNS 

Floreani et al have used the Design/CPN tool [11] to specify and verify a 
gateway between a narrowband packet radio network and a Broadband-ISDN 
network [7, 8]. The design of this gateway is complex, partly due its dis- 
tributed nature, and therefore, although the CPN formalism does not directly 
support incremental development, the methodology employed in the case study 
involves first developing and verifying an abstract specification of the system, 
then refining this specification. 

In this abstract model, Floreani defines a colour set containing the informa- 
tion required for setting up a call, and a colour set with this information plus 
addressing information. It is clear that this latter colour set is a type refinement 
of the former. 

As noted above, the substitution transitions supported by Design/CPN are 
like macros — they maintain structural compatibility, but not behavioural com- 
patibility. In both the abstract and refined models of this case study, substitution 
transitions are extensively used. For example, substitution transitions are used 
in the abstract model for sending (receiving) call information to (from) the 
gateway. These substitution transitions satisfy our requirements for transition 
refinement, and hence the explicit use of transition refinement would increase 
the clarity of the model and guarantee behavioural compatibility between re- 
finement and abstraction. 

The abstract model also defines the interfaces to the gateway and its internal 
structure — the gateway is represented by a single place. This was done to 
ensure correct behaviour of the interfaces before considering the behaviour of 
the gateway. (This is exactly the situation we see as typical of incremental 
development.) In the refined model, the place representing the gateway is 
replaced with a subnet. This subnet handles sending, receiving, and gateway 
call control. In the abstract model, when a connect indication is made or setup 
requested the appropriate token will always be accessible from the gateway 
place. This is not the case in the refined model, where a connect indication may 
be requested and fail because resources are not available, or if the destination 
address cannot be found. Similarly, a connect setup request may fail because 
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not enough resources are available. Hence the refined net fits our proposals 
for place refinement (see §2), but does not satisfy the strong substitutability 
requirements of the proposals in §3. 

4.2. INCREMENTAL MODELLING OF THE Z39.50 
PROTOCOL 

Another case study has explicitly considered the incremental modelling of 
the Z39.50 Protocol for Information Interchange [14]. The motivation for the 
incremental modelling was to capture the structure more clearly and to investi- 
gate whether such an approach could be used to capture the protocol evolution 
(from the 1992 to the 1995 version). Thus, the protocol entities were specified 
using a minimal message format which could then be refined at a later stage. 
This corresponds to the use of type refinement in our proposals. 

The provision of access control was also captured by the incremental modi- 
fication of the basic request service. Access control introduces an access rights 
challenge into the middle of the normal request-response interaction. Inade- 
quate access rights will lead to a different response from the server. Again, 
this possibility is compatible with our proposals for refinement but not with the 
more demanding proposals of §3. 

4.3. FIELDBUS PROTOCOL 

To meet new challenges in factory automation and process control, new local 
area network architectures, called Fieldbus Networks, have been proposed. The 
proposed architectures are hierarchical, where floor level devices (sensors and 
actuators), at low speed, are linked to their controlling devices and controlling 
devices can be linked among themselves at higher levels and higher speeds. The 
ISA/DLL protocol has been proposed to handle such distributed control, and 
has been modelled using Design/CPN [19]. The top-level view of the system 
is shown in fig. 8. 

All the transitions in that view are substitution transitions and capture the 
logic of the various devices. All the places are simple places which are used 
to convey delegation of commands and associated time slices to the devices. 
The LAS-Model captures the logic of the Link Access Scheduler with regard 
to arbitrating the synchronous and asynchronous delegation of commands and 
time slices to the various devices. The LAS-DLE is the Data Link Element 
for the LAS which therefore captures its own requirements for time slices. 
Three instances of sensors (which return information about device status) are 
indicated, as are three instances of actuators (which receive data to modify the 
device status). 

Time slices are allocated regularly to the devices according to their fixed 
requirements. This is known as the synchronous phase. Time is also allocated 
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Figure 8 Abstract view of the fieldbus protocol 



as available and as required for miscellaneous tasks such as data collection and 
error reporting. This is known as the asynchronous phase. When the LA5-Mo<ie/ 
wishes to perform the synchronous token delegation for a sensor, it deposits a 
token in the place CDl (for Compel Data 1) and then waits till the sensor 
relinquishes control and returns the relevant status information by depositing a 
token in the place DTI (for Data 1). The synchronous token delegation for an 
actuator only requires data to be sent (i.e. no response is expected) and hence 
is achieved by the LAS-Model depositing a token in the place CD2 (for Compel 
Data 2), whereupon the LAS-DLE deposits a token in the place DT2 (for Data 
2) which is consumed by the relevant actuator. The lAS-DLE also deposits a 
token in the place End-DT to indicate the time when the actuator will be ready. 

When the LAS-Model wishes to perform the asynchronous token delegation 
for sensors, actuators, or even itself, it deposits a token into the place Pol-Del 
and waits till a token is returned into the place Pol-Ret. Each device has a rather 
complex subnet for computing the time consumed out of the asynchronous time 
delegation and the possible further requests for time. 

For our purposes, the key point is to recognise that the above abstraction 
captures a lot of information about the behaviour of the system. Sensors and 
actuators have the notion of abstract firing in two different sets of modes — one 
set of modes relates to the synchronous token delegation, and one set of modes 
relates to the asynchronous token delegation. Each one of these consumes a 
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token and produces a token after some internal activity. (Actuators are slightly 
different in only consuming a token during the synchronous token delegation.) 
Thus, the substitution transitions for sensors and actuators basically satisfy our 
criteria for transition refinement. The abstract view will probably allow an 
arbitrary order of token delegation, while the refinement will constrain that 
order by the internal logic of the various components. 

However, as presented in the original paper, these substitution transitions 
exhibit further complexities. Firstly, they share information via place fusion. 
This is not supported by our definitions, but the same effect could be achieved 
by passing this information via additional interface places. Secondly, the sys- 
tem incorporates the notion of simulated time so that simulations can collect 
performance results. The incorporation of time into our proposals is a matter 
for further study. 

In summary, the above examples (as well as others we have examined [15]) 
illustrate the prevalence of incremental development of formal specifications. 
Our assessment is that our proposals are widely applicable, and their use would 
help to clarify the models and guarantee the behavioural compatibility which 
is often in the mind of the developer. 

5. FORMAL DEFINITIONS OF CPN REFINEMENT 

In this section we present the formal definitions of refinement as considered 
above. These definitions are abbreviated due to the constraints of space but 
an extended version can be found elsewhere [13]. CPNs are defined in §5.1, 
and CPN morphisms in §5.2. We identify the notion of system morphisms to 
capture the notion of refinement with behavioural compatibility, in contrast to 
the more traditional net morphisms which (only) specify structural constraints. 
The definition of our proposed refinements is given in §5.3. 

5.1. FORMAL DEFINITIONS OF COLOURED PETRI 
NETS 

We define Coloured Petri Nets in the context of a universe of non-empty 
colour sets S with an associated partial order <: C S x 2 which is derived 
from type compatibility in the theory of object-oriented languages [5]. X < \Y 
means that the values of X can be used in contexts expecting values of Y, and 
typically it means that X has extra data components over Y. In this case 
we assume the existence of a (polymorphic) projection function Ily from the 
values of X to those of Y (which do not appear in any proper subtype). For our 
purposes, we only make use of the fact that values of X are also values of Y. 

Given a universe of colour sets S, we define the functions over E as $E = 
{X -A- Y \ X,Y G 2}, the multisets over X as pX = {A N}, and 
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the sequences over X as aX = {xiX 2 . . .Xn \ Xi £ X}. (We usually name 
sequences with an asterix suffix.) 

Definitioii 5.1. A Coloured Petri Net AT is a tuple 
N = (P, T, A, C, E, M, Y, Mo ) where: 

a. P = set of places 

b. T = set of transitions, with POT = $ 

c. A = set of arcs, with A C (P x T) U (T x P) 

d. C = colours of places and (modes) of transitions, i.e. C : P\JT 

e. E = arc inscriptions with E : A ^ where E{p,t),E{t,p) : 
C{t)-^pC{p) 

f. M = set of markings, i.e. M = c) | p 6 P, c € C{p)} 

g. Y = set of steps, i.e. Y = //{(f, c) \t £T,c€ C(<)} 

h. Mo = initial marking. Mo G M 

Note that there is at most one arc in each direction for any (place,transition) 
pair and that the effect of an arc is given by the arc inscription in conjunction 
with a particular transition firing mode. The markings of N are multisets of 
(place,colour) pairs, while the steps are multisets of (transition,colour) pairs. 
While these are derivative quantities, they are included in the tuple so that later 
it will be clear that morphisms map markings and steps to markings and steps 
respectively. 

The above definition is, to all intents and purposes, equivalent to the common 
definition [10]. It does not include a guard function defined on transitions, 
but the same effect is achieved by limiting the colour set associated with the 
transition. 

Definition 5.2. For a CPN N, x E P UT, X CPUTwe define : 

a. the inputs of x, ' x = {y E P U T \ {y, x) E A} 

b. the outputs of x, x' = {y E P CT \ {x, y) E A} 

c. the border of X, bd{X) = {x E X \ 3y E P UT \ X : y E 'x U a:*} 

d. the environment of X, env{X) = {yEPiJT\X\3x EX :yE 
'x U a;*} 

Thus, the border of a set of nodes X, are those nodes connected to other 
nodes not in X, and those other nodes constitute the environment of X. 
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Definition 5.3. The incremental effects ^ E : Y — > M of the occurrence 
of a step Y are given by: 

a. E-(Y)= Z Z {p} X E{p,t){m) 

(t,m)eY (p,t)eA 

b. E+{Y) = Z E W X Eit,p){m) 

{t,m)eY {t,p)eA 

The enabling and firing of steps and sequences is defined in the usual manner: 

Definition 5.4. For a net CPN, N, a step F G Y is enabled in marking M 6 M, 
written M\Y), if M > E~{Y). If a step F € Y of CPN N is enabled in 
marking Mi G M, it may fire leading to marking M 2 G M, written Mi[F)M 2 
with M 2 = Ml — E~{Y) + £?+(F). A step sequence F* = F 1 F 2 • • • G 
(tY of a CPN N is enabled in marking M\ G M and may occur, leading 
to marking M 2 G M, written Mi[F*)M 2 if there exists intermediate markings 
M^, M^, . . . , M4 G M such that Mi[Fi)M^, M/[Fi)M^+i for i G 2, . . . , n- 1, 
and M^[y^)M 2 - The set of reachable markings C M is given by = 
{M G M I 3F* G crY : Mo[F*)M}, and the set of enabled step sequences 
Y^ C aY is given by: Y^ = {F* G crY | 3M G M : Mo[F*)M} 

Definition 5.5. For CPN N step F G Y is realisable by F" G crY in marking 
Ml G M leading to marking M 2 G M if Mi[F*)M 2 and E 2/ = 

y€Y- 

Note that if a step F is enabled in marking M, then it is realisable by F. 

5.2. THE FORMAL DEFINITION OF CPN 
MORPHISMS 

This section defines morphisms between CPNs and distinguishes between 
net morphisms (which respect structure) and system morphisms (which respect 
behaviour). 

Definition 5.6. A net morphism <f> : N N' is a. mapping from N to N' which 

is structure-respecting, namely: 

a. 4> is surjective with respect to P',T',A' 

b. Y{x,y) G An(FxT) : <j>{x) = 4>{y) V {<f>{x) , <f,{y)) G A'D(P'xT') 

c. Y{x,y) G An(TxP) : (j){x) = <t>{y) V {(p{x),(f>{y)) G A'D(T'xP') 

This is the common definition of net morphism (albeit with various addi- 
tional constraints) which is primarily concerned with respecting the adjacency 
properties of the net [3, 21]. It does not constrain behaviour (except indirectly) 
— in fact, sets of markings and steps are not normally included. It also does 




250 



not encompass restriction on places and transitions, i.e. where selected places 
and transitions (and their associated arcs) are ignored. 

We only consider morphisms which are surjective with respect to P', T', and 
A'. (This means that every abstract component is the image of some refined 
component(s). In other words, a refinement never deletes abstract components.) 
Consequently, we can define the preimage of every node. 

Definition 5.7. Given a morphism <f> : N ^ N' and x' E. P' Li T' we define 
the preimage by N^' = (f>~^{x') and write 
N 2 ;/ = ^Px ’ ) Px* ? Ax * , Cx* J Px' ? ^^Ox ' ) • 

In order to define the behaviour respecting properties of a system morphism, 
it is desirable to consider complete steps, since the firing of multiple transitions 
in the refinement may correspond to the firing of one transition in the abstraction. 

Definition 5.8. Given a morphism (p : N N', a step y of iV is complete if 
Vt' eT':\/tE bd{Nt') : x F(t)) = {t'} x (f>{Y)it') 

Thus a step is complete if all border transitions occur with matching modes 
(which also match the mode occurrence of the corresponding abstract transi- 
tion). 

Definition 5.9. A system morphism cp : N N' is & mapping from N to N' 
which is behaviour-respecting, namely: 

a. (p is surjective with respect to P',T', A! 

b. (p is linear and total over both M and Y 

c. VM G Mr : Vy € Y : 

y is complete and realisable as yiy 2 . . . Yn at marking M => 

(p{Y) is realisable as (p{X\)(p{Y 2 ) ■ • • 4>(Xn) at marking (p{M). 

d. VM € Mr : Vy G Y : y is complete 

m + E+{Y) - E-(Y)) = <P(M) + <P{E+mY)) - 4>{E~){4>{Y)) 

Note that if the refined step is complete then its realisation can be used 
to derive the realisation of the corresponding abstract step, by projecting or 
restricting each component step. The modified rule of part (d) for the effect of 
a refined step (cf. [23]) is used since we cannot consider the component steps 
(of its realisation) in isolation. Thus, part (c) guarantees the enabling of the 
abstract sequence, while part (d) captures its overall effect. 

The above definition clarifies what we mean by behaviour-respecting, also 
called behavioural compatibility. This kind of morphism is called a system 
morphism in line with the common Petri Net distinction of a net concerning 
the structure and a system including behaviour. This definition captures the 
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requirement that we identified earlier, namely that a complete refined behaviour 
has a corresponding abstract behaviour. 

Given two system morphisms <pi : N N' and (j >2 '■ N' N" their 
composition ^ = ^2 ° : N -A N" is a system morphism (see the proof 

in [13]). This means that we can combine the different forms of refinement 
(considered in the subsequent section) and we still have a system morphism. 

5.3. CPN REFINEMENTS 

We now consider each of the proposed kinds of refinement. In each case, the 
terminology reflects the way the incremental change is used, i.e. fi'om abstract 
to refined, but the morphism is always a mapping from refined to abstract. 

5.3.1 Type refinement. The first, and perhaps simplest, form of re- 
finement is to retain the structure of the net without modification but to replace 
some (or all) of the token and mode types by subtypes. Given our formulation 
of CPNs, where the arc inscriptions are functions (fi'om modes to token mul- 
tisets), it may not even be necessary to change the arc inscriptions, provided 
that they are given by polymorphic functions. The distinctive thing about type 
refinement is that there is a projection function from subtype to supertype so 
that every refined state or action has a corresponding abstract state or action. 

Definition 5.10. A morphism (f> : N N' captures a type refinement if: 

a. </> is an identity function on P, T, A, i.e. \/p E P : <f>{p) € P, etc. 

h.^xG PUT: C{x) <: <f>{C){x) 

c. Va: G PUT : Vc e C(x) : (j){V {x,c)) = V {x,U^(^c)ix){c)) 

d. W{p,t) G A:V(f,c) G Y: 

{t,c)))(p) = n^(c,(p)(P(p,f)(c)) = 

V(p,f) G A:V(f,c) G Y: 

<f>{E+{V {t,c)))(p) - n^(o(p)(P(t,p)(c)) = fi{E){t,p){U^^cmic)) 

Note that there is no change to the structure of the net — to places, tran- 
sitions and arcs, but the colours associated with the places and transitions are 
consistently subtyped. The use of the appropriate projection functions gives the 
corresponding abstract marking and step for every refined marking and step, and 
the projected effect of a mode or step is the same as the effect of the projected 
mode or step. 

It is a simple matter to prove that a morphism which captures a type re- 
finement is a system morphism (see [13]). It is important to note that the 
conditions required by such a morphism can be statically checked. In §2 we 
gave an example of type refinement, where the book token type was extended 
with information about the kind of loan. 
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5.3.2 Subnet refinement or extension. The second form of refinement 

is to add net components — places, transitions and arcs, or even additional token 
or mode values. As a morphism (from refined to abstract nets), this would be 
called a restriction, since net components are being discarded or ignored. Where 
token or mode types are extended, then in contrast to §5.3. 1, abstraction does not 
project the additional refined values onto abstract values but rather ignores them. 
(In the equivalent unfolded PTN, this is the same as ignoring places, transitions, 
and arcs.) This does not satisfy the structure-respecting requirements for a net 
morphism (def 5.6), but is does qualify as a system morphism (def 5.9). 

Definition 5.11. A morphism 4> ■ N N' captures a subnet refinement if: 

a. The net structure is restricted, i.eVp € P : fiip) is defined => (p{p) E P 
and similarly for T, A. 

b. Va; € (f>{P) U (/>(T) : C{x) D 4>{C){x) 

c. Va; G PUT ; Vc € ^(a;) : 0(1' (a;, c}) = 1' (a;,c) if a; G 0(P)U0(T) 
and c G <f>{C{x)), otherwise 0. 

d. vy G Y : 0(p+(y)) = 0(p+)(0(y))and0(p-(y)) = 0(p-)(0(y)) 

Note that the sets of places, transitions, and arcs, may be restricted by <f>, 
and that the colours associated with retained places and transitions may be 
restricted by <f>. Again, the morphism is defined for all markings and steps and 
the restricted incremental effect of the step is the same as the incremental effect 
of the restricted step. This implies that ignored components can refer to, but 
cannot permanently modify, retained components. 

Again, it is not difficult to prove that a morphism which captures a subnet 
refinement is a system morphism (see [13]). It is important to note that the 
condition for such a morphism can also be statically checked. In §2 we gave 
an example of subnet refinement, where the subnet was augmented to cater 
for book reservations. The abstract behaviour of the net was restricted by the 
refinement — if a book can be borrowed given the possibility of reservations 
(the refined case), then it can also be borrowed if reservations are ignored (i.e. 
the abstract case). 

5.3.3 Node refinement. The third form of refinement is the replace- 
ment of a place (transition) by a place (transition) bordered subnet. We re- 
fer to this as node refinement to distinguish it from the other forms of re- 
finement being considered, even though traditional Petri Net theory simply 
refers to it as refinement [3]. The desirable properties of node refinement for 
CPNs have been considered elsewhere [12]. For behavioural consistency, it 
was argued that the subnet which refines a place should have the notion of 
an abstract marking, and the subnet which refines a transition should have the 
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notion of abstract firing. These constraints were captured by requiring the mor- 
phism to be stmcture-respecting, colour-respecting, marking-respecting and 
step-respecting. A structure-repecting morphism is a net morphism of def 5.6. 
A colour- respecting morphism is one where the colours of border places (tran- 
sitions) of a refined component match the colours of the corresponding abstract 
component, and where the flow of tokens across the refined node boundary 
matches the flow of tokens for the abstract node. A marking-respecting mor- 
phism determines the marking of an abstract place from the marking of the 
corresponding place refinement. Further, this abstract marking is not modified 
by internal actions of the refined node. Finally, a step-respecting morphism 
is one where a step sequence of a transition refinement maps into a firing of 
the corresponding abstract transition provided the border transitions occur with 
matching firing modes. 

Here, we have proposed canonical place and transition refinements, which 
satisfy the above constraints and are quite general (see [13]). In any case, it 
turns out that the morphism for a node refinement is both a net morphism and 
a system morphism. 

Given the length of the formal definitions for canonical place and transition 
refinements, we omit them here but refer the reader to the informal presentation 
in §2 and the formal definitions in [ 1 3] . Again, it is not difficult to show that these 
canonical node refinements are system morphisms and that their conformance 
to the definitions is statically checkable. 

The canonical transition refinement is the only form which does not have 
the property that every refined step sequence has a corresponding abstract step 
sequence with matching abstract states. Instead, this property holds if and only 
if the refined step sequence is complete, i.e. it contains matching occurrences 
of the border transitions of the refined transition(s) [13]. 

In §2 we gave examples of node refinement, one where a place was replaced 
by a subnet to indicate the more detailed processing of a book on its return from 
loan, and one where a transition was replaced by a subnet to indicate more of the 
details of borrowing a book. Again, such refined behaviour had corresponding 
abstract behaviour, but not necessarily vice versa. 

It is important to emphasise that in each kind of refinement considered above, 
i.e. type refinement, subnet refinement, and node refinement, the criteria for 
acceptable refinements can be statically determined. 

6. CONCLUSIONS AND FURTHER WORK 

This paper has argued that the object-oriented specification of concurrent 
and distributed systems has tended to emphasise substitutability at the expense 
of code reuse. As a result, the various proposals in the literature tend to be bet- 
ter suited to the replacement of one system component by another, rather than 
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supporting the incremental development of specifications. We have attempted 
to remedy this in the context of the Coloured Petri Net formalism by proposing 
three forms of refinement — type refinement, subnet refinement and node refine- 
ment. Examination of case studies in the literature seem to suggest that these 
forms of refinement are widely applicable in practice [15]. The behavioural 
compatibility requirements which they impose seem to match the kinds of ab- 
straction that designers use in the process of incrementally developing formal 
specifications. 

Recently, we have been developing state space analysis algorithms which 
will take advantage of the information supplied by the refinements proposed in 
this paper [17]. The basic approach is to use the analysis of the abstract model 
to restrict the possibilities considered in the refined model. (This approach rests 
on our basic requirement for behavioural compatibility.) If the net is refined 
by type or subnet refinement, the state space algorithm uses the abstract net to 
determine the firing modes that might be enabled for each state of the refined 
net. This reduces the time taken to search for the enabled firing modes at each 
state of the refined net. Where node refinement is used, the algorithm reduces 
the interleaving of states by computing the reachable states of each refined node 
separately, thus improving both the time and space required to generate the state 
space. 

Preliminary results indicate that the percentage improvement (compared to 
the standard algorithm) is heavily dependent on the structure of the abstract 
and refined nets. For each of the forms of refinement, in certain cases we have 
observed greater than 95% time improvement. For node refinement we have 
also observed significant space improvement. Clearly, there is scope for further 
work in determining the efficiency improvements which are possible using the 
proposed refinements, and also for characterising the situations where such 
improvements are maximised. 

Since this work is driven by the desire to support practical development 
techniques, it would obviously be helpful to extend our examination of case 
studies demonstrating incremental development of specifications. It would 
also be desirable to formalise the relationship between our proposals and others 
in the literature in an attempt to bridge the gap between them. For example, it 
would be worthwhile formulating minimum criteria under which every abstract 
firing sequence has a corresponding refined firing sequence. 
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Abstract In this paper we describe how we can refine both objects and operations 
in an Object-Z specification. In particular, we will be concerned with 
changes of granularity of both objects and operations. Objects in that 
we wish to change the structure of objects in a specification. Operations 
in that we wish to provide explicit support for action refinement in this 
language. There axe clear advantages in being able to change such 
levels of granularity when performing a refinement. In this paper we 
discuss the issues surrounding such refinements and derive general rules 
to support their use. We illustrate our ideas by looking at a specification 
of a cash point machine at a bank. 

Keywords: Object-Z; Refinement; Action refinement; Object structure. 

1. INTRODUCTION 

In this paper we illustrate, through a worked example, how we can 
refine the granularity of both objects and operations in Object-Z. 

It could be argued that one of the principal problems of designing a 
system formally is the need to fix an appropriate level of abstraction 
when initially describing the system. In particular, designers need to 
choose the granularity of the operations or events in the initial model 
and there is a balance to be found between too few events arising from 
a very abstract view or too many events which can clutter the under- 
standing (and indeed verification) of the system. Furthermore, in an 
00 notation the granularity of objects must also be fixed in the initial 
specification, and again there is a tension between a suitably abstract 
view vs the actual division of objects appropriate in an implementation. 
For example, an implementation may require objects to be distributed 
across several nodes, whereas in the initial specification such detail is 
neither relevant nor helpful. 
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The problem arises because there is little support for changing the 
granularity of specifications when they are developed. Development in 
the context of formal specification means the use of refinement, imple- 
mentation or testing relations which define the acceptable implementa- 
tions of a specification, usually on the basis that the implementation 
exhibits behaviour that was feasible in the original specification. Exam- 
ples of development relations include data refinement in Z [8, 15], the 
failures-divergences preorder in CSP [9], and reduction in LOTOS [4]. 

However, the majority of these relations leave the granularity of com- 
ponents (e.g. operations and objects) unchanged. For example, refine- 
ment of events is usually atomic, an event cannot be broken down into its 
constituent parts under a refinement. It is this that forces the developer 
to retrofit the level of granularity in the initial specification. Clearly 
there would be many benefits in being able to change the granularity of 
both objects and operations in a refinement, and the purpose of this pa- 
per is to describe a solution to this problem in the specification language 
Object- Z. 

Object-Z [7] is an object-oriented extension of the Z [12] notation, 
and there has been a certain amount of interest in using Object-Z to 
specify distributed systems, particularly within the ODP initiative. An 
Object-Z specification consists of a number of interacting classes and 
objects. Each class consists of a state space, an initialisation together 
with a collection of operations which change the state and thus define 
the behaviour of the class. 

In Object-Z and Z the implementation relation is called data refine- 
ment [14]. The principle of data refinement is that the more concrete 
specification can reduce any non-determinism present in the abstract 
specification. To verify a refinement a retrieve relation is used which re- 
lates the concrete to abstract states and allows the comparison between 
the data types to be made on a step by step basis by comparing an 
abstract operation with its concrete counterpart. 

The main work on refinement in state-based specification languages 
has been in a non-object-oriented setting, however there has been some 
related work on refinement for object-oriented formal methods. For ex- 
ample, a definition of refinement for Object-Z has been given in [11], 
however, a restricted subset of Object-Z wats used where classes could 
not contain objects as state variables. In this paper we relax that re- 
striction and show how we can use the definition of refinement to change 
the structure of objects in a specification. 

In addition to objects the other aspect we consider is that of opera- 
tions. The step by step comparison of operations that refinements make 
is possible because the specifications are assumed to be conformal [8], 
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i.e. there is a one-one correspondence between abstract and concrete op- 
erations, so each abstract operation has a concrete counterpart. In this 
paper we relax that assumption to discuss refinements where an abstract 
operation is refined by, not one, but a sequence of concrete operations. 
Providing such an action refinement will help solve the problem men- 
tioned above, namely it will allow a natural change of granularity to 
be expressed as part of the development process. This could also en- 
able interleavings of concrete operations which might be necessary for 
efficiency reasons. 

Action refinements arise naturally in a number of settings. The par- 
ticular example we will look at is a cash point machine with an operation 
that requires as input a sequence of digits representing the p.i.n. of the 
user. At the abstract level this is described cis a single atomic operation, 
but at the concrete level we may wish to dispense with this assumption 
and specify the process of entering the input digits one by one. 

Such action refinements have been extensively discussed in the con- 
text of process algebras, usually under the name of action refinement 
[2, 10]. The difficulty in a process algebra is due to the interleaving 
semantics and in particular the law that a\\b = a; b \\ 6; a. Incorpora- 
tion of action refinement and the requirement that semantic equivalences 
should be congruences with respect to refinement means that the natural 
interleaving semantics has to be abandoned. 

However, in Object-Z and Z there are no such constraints because 
there are no global behavioural constructors such as || in a process al- 
gebra. The II primitive in Object-Z is a schema calculus operator which 
builds a single new operation rather than defining a temporal constraint 
over existing behaviours. So the situation which causes the problem in a 
process algebra never occurs in a state-bcised language (i.e. the standard 
semantics can be used and equivalences all still hold). There are some 
simple examples of action refinements in state-based languages, e.g. pro- 
tocol refinements in B [1], in Z [14] and buffers in B [5]. These approaches 
introduce a skip operation (i.e. stuttering step) in the abstract specifi- 
cation. Such an operation produces no change in the abstract state, and 
the concrete system is constructed so that one of the concrete operations 
refines the abstract operation whilst the other refines skip. 

However, although some action refinements can be verified in such a 
manner we wish to go further and consider refinements where we split 
a collection of inputs or outputs across several concrete operations as in 
our cash point example. Because we are transforming the inputs/outputs 
in this fashion the concrete operations don’t refine skip^ and such a 
refinement cannot in general be verified using abstract stuttering steps. 
In this paper we develop machinery to verify action refinements where 
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the inputs/outputs can be split and combined across the operations in 
a concrete decomposition. 

The structure of this paper is as follows. In Section 2 we discuss the 
standard notion of refinement in Object-Z. In Section 3 we illustrate how 
we can refine the class structure of a specification and thus change the 
granularity of objects during development. Section 4 goes on to discuss 
the problem of decomposing operations in a refinement, and Section 5 
looks at the solution. 

2. REFINEMENT IN OBJECT-Z 

In this section we discuss how to refine an Object-Z specification. The 
definition of refinement in Object-Z is a simple adaption of refinement in 
Z. That is, refinement of a class ^4 by a class C requires that we relate the 
two classes by a retrieve relation linking the state spaces in the abstract 
and concrete classes. Then the initial states of the classes must be related 
in the standard fashion and each abstract operation in class A must be 
matched by a concrete counterpart in C such that the preconditions are 
identical modulo the retrieve relation (but not weakened because of the 
meaning of preconditions in Object-Z), and the effect of the concrete is 
consistent with the behaviour of the abstract. 

This assumes the specifications are conformal, i.e. for each abstract 
operation AOp there is exactly one concrete operation COp, It also 
assumes that the inputs and outputs of the concrete operation are iden- 
tical to those of the abstract operation. For the moment we will assume 
this, but in Section 4 we will relax this condition when we decompose 
individual operations. 

We can summarise the requirements of refinement in Object-Z in the 
following definition, where A. State denotes the state schema in the class 
A etc, and AJnit denotes the initialisation. 

Definition 1 Object-Z refinement 

An Object-Z class C is a refinement of the class A if there is a retrieve 
relation R such that every visible abstract operation AOp is recast into 
a visible concrete operation COp and the following hold. 

1 V C. State • (7. /nit {3A.State • A.Init A R) 

2 \/ A. State; C. State • pre AOp A R <==> pre COp 

3 y A. State; C. State; C. State’ • RACOp 3 A. State' • R'AAOp 

One difference between refinement in Z and refinement in Object-Z is 
in the treatment of preconditions of operations. Refinement in Object-Z 
requires that preconditions are preserved (condition 2 above), whereas 
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in Z preconditions can be weakened under refinement. This arises due 
to different interpretations of a partial operation in Z and Object-Z. In 
Z the meaning of an operation specified as a partial relation is that it 
behaves as specified when used within its precondition, and outside its 
precondition, anything may happen. However, in Object-Z the operation 
is not enabled outside its precondition. Therefore guards cannot be 
modelled in Z since all operations are always enabled, whereas in Object- 
Z outside the precondition an operation will be refused. 

An example of refinement in Object-Z using this definition appears 
in [11] where a restriction is made that classes do not contain object 
instantiations. In fact the above definition can serve as a definition 
of refinement between arbitrary Object-Z specifications (not just two 
classes) because each Object-Z specification has a main class through 
which the behaviour of the whole specification is viewed. One Object-Z 
specification is then a valid refinement of another if the main class of 
the first is a refinement of the main class of the second. 

We look at two aspects of refinement in this paper. The first will be 
to see how we can refine the class structure of the specification by intro- 
ducing a number of communicating objects in a refinement. Secondly 
we will relax the assumption of operation conformity made above. The 
starting point for this will be to consider the consequences of refining an 
abstract operation into more than one concrete operation. In doing so 
we will need the generality of 10 refinement [3] which allows inputs and 
outputs to change under a refinement in a controlled manner. 

Notation. The schema calculus composition (§) and piping (2>) oper- 
ators are used frequently. The composition operator acts as composition 
on the state spaces of two operations, so COpi § COp 2 is a new operation 
formed by considering the operations as relations on the state space. In 
such a composition the declarations of COpi and C0p2 are merged. The 
piping operator acts as composition on the inputs and outputs of two 
operations, and thus can be seen as a one way communication of the out- 
puts of the first into the inputs of the second operation. We also use the 
parallel composition operator, ||, which defines two way communication 
between two operations. 

3. DECOMPOSING OBJECTS IN A 
REFINEMENT 

We now show how we can use the definition of refinement given above 
to verify refinements where a class is split into a collection of interact- 
ing classes. By developing refinements such as these we can support a 
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change of granularity of the objects in the system. Initial designs can 
then contain few objects, representing an abstract view of the system’s 
functionality, and refinements can change this granularity by introducing 
perhaps many objects which refiect the structure of a final implementa- 
tion. 

In our example the initial specification consists of a single class ATMq 
which describes a cash point machine. The behaviour of the class is 
defined by operations Insert-card^ Passwd^ Withdraw etc. A user of 
the machine inserts a card which is modelled by reading the account 
number account!. A four-digit p.i.n. is then given, and if this matches 
the account then the user is able to proceed and Withdraw money. 

The bank accounts are modelled as a partial function accts from ac- 
count numbers to amounts. The p.i.n. for a given account m is given by 
pins{m). The card currently inside the machine is represented by card., 
and we use a boolean to determine whether a transaction is allowed to 
proceed. 



ATMo 

accts : N -+> N 
pins :N-f>NxKxKxN 
card : N 
proceed : B 

dom acc^5 = dom pins 

Init 

card = 0 A -^proceed 



Insert-card 

A{card, proceed) 
account! : N 

card = 0 A account! E dom pins 

-^proceed’ 

card' = account! 
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Passwd 

A(proceed) 

pin? : N X N X N X N 
card 7 ^ 0 

pins {card) = pin? => proceed' 
pins {card) ^ pin? ^proceed' 



Withdraw 

A{accts) 
moneyl : K 

proceed 

accts' = accts 0 {card i-> accts{card) — moneyl} 



In an implementation the branch of a user is not necessarily co- located 
with the cash point being used, and we therefore want to split this 
description into two separate classes: Bank and CashPoint. These are 
given as follows. 



, Bank 



accts : N N 



Withdraw 

A{accts) 
moneyl : N 
acct? : N 

accts' = accts © [acct? t-> accts{acct?) — moneyl} 
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, Cashpoint 



pins :K-+>NxNxNxlM 
card : N 
proceed : B 



Init 

card = 0 A -^proceed 



Insert^card 

A ( card , proceed ) 
account? : N 

card = 0 A account? G dom pins 

-^proceed' 

card^ = account? 



Passwd 

A (proceed) 

pin? : N X N X K X N 
card ^ 0 

pins (card) = pin? => proceed' 
pins (card) ^ pin? => -^proceed' 



Proceed 

proceed\ : B 
acct\ : N 

proceedl = proceed 
acctl = card 



The complete behaviour, including communication between the two 
components, is given by the main class ATM\, This includes a bank and 
a cash point, and it promotes operations from these objects to the overall 
class. A customer can then Withdraw from the bank when the cash 
point gives permission to proceed and has communicated which acctl 
permission is being granted for. The communication || then identifies 
acctl with acct? in Withdraw and the correct account is debited. 
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ATMi 

c : Cashpoint 
b : Bank 

dom b.accts = dom c.pins 



Init 

c.Init 

Insert-card = cJnsert-card 
Passwd = c.Passwd 

Withdraw = {b. Withdraw \\c. Proceed • [proceedl = true]) 
\{proceed\} 



Then we claim that ATM\ is a refinement of the class ATMq. To show 
this formally we need to define a retrieve relation between the two main 
classes, and we use the following, where we have prefixed each variable 
name by the name of the class to keep the variable names distinct. 

R 

ATMq. State 
ATMi. State 

ATMo.accts = ATM\.b.accts 
ATMo.pins = ATM\. c.pins 
ATMq. proceed = ATM\.c. proceed 
ATMq. card = ATM\.c.card 



We then have to show that the conditions in Definition 1 hold. We 
concentrate on the conditions for the operations here, and for every 
operation we have to verify correctness and applicability. For example, 
for the Insert-card operation we need to verify that 

pre ATMq. Insert-card A R 4=^ pre ATMi.Insert-card 
R A ATM\. Insert-card 

=> 3{ ATMq. State)' • R' A ATMq. Insert -card 

In order to do this we note that the use of object instantiation (e.g. 
banks and cash points) means that we need a way of interpreting the 
preconditions, the state spaces and the retrieve relation in their presence. 
Once we have done that the verification should be straightforward. 

For the state space we define {ATMq. State)' to be ATMq. (State)' ^ 
with the process being applied recursively if there are further object 
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instantiations. This allows the refinement conditions to access the state 
variables of an object used in a refinement, and this is necessary since it 
is the state variables that alter when an operation is invoked upon that 
object. 

Thus ATMq. State' and ATM\, State' will be 



A TMq . St A te' 

accts' : N N 
pins' :N-h>NxNxNxN 
card' : N 
proceed' : B 

dom accts' — dom pins' 



A TMi . State' 

c. St ate' 
h. St ate' 

dom b. accts' = dom c, pins' 



The latter being: 



b. accts' : N -+> N 

c. pins' :K-+>NxNxlS[xK 
c.card' : N 

c. proceed' : B 

dom b. accts' = dom c.pins' 



This interpretation is what we require. Without it {ATMi. State)' 
would be 



c' : Cashpoint 
b' : Bank 

dom b'. accts = dom c' .pins 



However, this is incorrect because when the object b evolves its internal 
state changes but the references to it is still denoted by b and not by b'. 
So {ATMi. State)' must contain primed references to the components 
actually altered by the operations, i.e. b. accts' and not b' itself. 

This definition then allows us to interpret the state spaces in the 
schema R' so that it can be used in the refinement conditions as desired. 
We also need to calculate preconditions such as AT M\. Insert -card ^ that 
is to be able to calculate pre ATMi. c. Insert -card. In order to do this 
we need to define pre a. Op for an object a with operation Op. pre a. Op 
should be a schema representing those states where it is possible to apply 
Op on a. Since this depends on the current state of a, we define pre a. Op 
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to be a.pre Op^ as the latter defines a schema representing states in a 
when Op is applicable. 

Definition 2 Let A be an Object-Z class containing an operation Op. 
Suppose that the state declaration a : A appears in another class, then 
in that class prea.Op is defined to be a.pre Op. 

With these definitions in place we can verify the refinement conditions 
above. For example, applicability for Insert-card now requires that 

{card = 0 A account! G dom pins) 

A {pins = c.pins A card = c.card) 

c.card = 0 A account! G dom c.pins 

Similarly correctness requires that 

{pins = c.pins A card = c.card A . . .) A 
{c.card = 0 A account! G dom c.pins A 
^c. proceed’ A 
c.card’ = account!) 

3 ATMq.State’ • {pins’ = c.pins’ A card’ = c.card’ A . . .) A 
{card = 0 A account! G dom pins A 
-^proceed’ A 
card’ = account!) 

which are easily seen to be true. The conditions for the other operations 
are similar. 

To summarise, what we have done here is to use the basic refinement 
conditions to verify refinements where we change the granularity of the 
objects in the specification. We have done this by using the standard 
conditions, but interpreting them appropriately in the presence of object 
instantiation. 

4. DECOMPOSING OPERATIONS IN A 
REFINEMENT 

Having decomposed our initial single object into a number of commu- 
nicating objects we will now look at the issue of decomposing individual 
operations, i.e. look at action refinement in Object-Z. The situation we 
wish to provide support for is an abstract specification containing an op- 
eration AOp, and a subsequent refinement where AOp is implemented 
as a sequence of concrete operations: COpi followed by COp 2 - 

The assumption of conformity in the standard refinement rules means 
that there is one concrete operation for each abstract operation. If we 
are to decompose AOp into COpi § C0p2^ then one choice we could make 
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would be for COpi to refine A Op, and for C0p2 to refine a stuttering 
step skip, which makes no change in the abstract state. This preserves 
the conformity of the two specifications and so simple action refinements 
can be verified as two sets of rules, one for refining A Op into COpi and 
the other for refining skip into COp 2 - 

The requirements on COp\ refining A Op are the standard ones and 
the requirements on refining skip to COp 2 are: 



V A. STATE’, C. State • R pre COp2 
y A. State; C. State; C.State^ • 

R A COp2 => 3 A.State’ • EA. State A R' 



It is in this context that the action refinements given in [14, 5] are 
verified. 

However, we wish to go further than this and we want to be able to 
split the input and output across the concrete decomposition. If we do 
so then the operations in the concrete decomposition will not correspond 
to abstract skips. An example will make it clear why this is the case. 

Consider the CashPoint, The Passwd operation accepted the pin in 
one go, but in an implementation we wish to accept the 4 digits one at 
a time, with each digit being entered by a separate operation. We are 
therefore going to split this single operation into a sequence consisting of 
4 operations: First, Second, Third and Fourth. Note that, as usual, the 
denial to proceed is only fiagged after all the digits have been inserted. 
(The definitions of Insert -card and Proceed are as before and are elided.) 



CashPointi 

pins :N-+>NxKxNxN 
card : N 
proceed : B 
temp : seq^ N 



Init 

card = 0 A temp = ( ) 

Insert-card = . . . 
Proceed = . . . 
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First - 

A{temp) 
d? : N 

card ^ 0 

temp = ( ) A temp' = (d?) 



Second 

A{temp) 

d?:N 

fj^temp = 1 A = temp ^ (d?) 



T/iird 

A{temp) 
dl : N 

fj^temp = 2 /\ temp' = temp ^ {dl) 



^ Fourth 



A(proceed) 
dl :K 




iftemp = 3 

pins {card) = temp ^ 

pins {card) ^ temp ^ 


(dl) => proceed' 
(dl) => -^proceed' 



We would like to view this as a refinement of CashPoint. However, the 
refinement cannot be verified by making of one of the concrete operations 
refine Passwd whilst the others refine skip. 

The problem with the refinement is the following. Clearly the retrieve 
relation has to be the identity on the state spaces, and therefore abstract 
skip operations can be refined by concrete operations which only change 
temp. Therefore First, for example, looks a suitable candidate to refine 
skip. However, First (and all the other operations) consumes input, 
therefore it alters the state (as a result of changing the environment) 
and thus does not correspond to skip. The problem is that the inputs of 
Passwd are distributed throughout the concrete operations. This means 
that the rules as they stand can’t be used to verify a refinement in 
general. The rest of this paper is devoted to developing the necessary 
machinery to solve this problem by adapting action refinement rules 
developed for Z [6]. 
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5. ACTION REFINEMENT 

In this section we will consider refinements where we decompose an 
abstract operation into a sequence of concrete operations without requir- 
ing that any of the concrete operations refine an abstract skip operation. 
This will solve the problems identified in the example above. 

To do so we will apply and extend the technique of lO-refinement to 
address the issue of decomposing inputs and outputs across a sequence of 
concrete operations. Our example illustrates what we wish to achieve: 
Passwd takes an input pin! : N x N x K x N and breaks it down 
into single inputs d? : N provided a number of times in the concrete 
operations. 

To solve this problem we drop the condition that when we decompose 
AOp into COpi § COp2 one of the concrete operations refines A Op and 
the other refines skip. This means that AOp can be replaced by COpi 
followed by COp2^ however, if the concrete object performs a single 
instance of COpi (not followed by COp2) then this won’t necessarily 
simulate anything at the abstract level. Indeed this may be viewed as 
exhibiting a deficiency of the abstract cash machine specification: it does 
not represent the (realistic) situation where a user only ever enters one 
of the digits of their p.i.n.. 

This is the situation in our example. Passwd is refined by the sequence 
First g Second g Third g Fourth., however, a single instance of First does 
not correspond on its own to any abstract level operation, but only a bit 
of Passwd^s functionality. 

With the single requirement that AOp is refined by COpi g COp2 
we can now describe the conditions necessary for a refinement to hold. 
Without considering any input and output transformations at this stage 
the formulation is as follows (we omit consideration of the initialisation 
condition as that is unaltered). 

Definition 3 Action refinement without 10 transformations 
The retrieve relation R defines an action refinement between two classes 
(where the abstract operation AOp has been decomposed into a sequence 
of concrete operations COpi g COp2) if the following hold. 

y A. STATE] C. STATE] C .StATE' • 

{COpi g COp 2 ) AR^3 A. State' • R' A AOp 
M A. STATE] C .State • preAOp A R preCOpi 
V A. STATE] C. State • pre AOp A R A COpi ^ pre COp2 

These conditions generalise to an action refinement with an arbitrary 
number of concrete operations in the obvious manner. 
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The conditions in Definition 3 express the following requirements. The 
first says that the effect of COpi § COp 2 is consistent with that of AOp 
(but can of course reduce any non-determinism in AOp). The second 
says that COp\ can be invoked precisely when AOp can be, and the 
third says that when (and only when) COpi has been completed COp 2 
can be invoked. Informally these are clearly the correct conditions for 
a refinement of AOp into COp\ § COp 2 - Formally they can be derived 
from the relational basis of refinement in the same way that [6] gives the 
relational basis for action refinement in Z. 

This definition is sufficient to verify the applicability conditions for the 
example above, but for correctness we need some input transformations. 
To see this note that if we calculate {First g Second g Third g Fourth) 
we find that we have lost the differentiation between the inputs in the 
concrete operations, i.e. this schema composition results in: 



A(proceed) 
d? : N 

card 7 ^ 0 
temp = { ) 

pins{card) = (d?, d?, d?, d?) proceed' 
pins(card) ^ (d?, d?, d?, dl) => -^proceed' 



which covers only a very limited range of 4-digit p.i.n. codes, and is 
certainly not the same as Passwd. 

5.1. ALTERING THE INPUT AND OUTPUT 

We now consider the transformations of input and output that are 
needed to support action refinements. To do so we will use 10 refinement 
in our action refinements to produce a set of conditions that allow inputs 
and outputs to be distributed throughout a concrete decomposition. 

10 refinement [3, 13] is a generalisation of the standard Z refinement 
rules, which are normally given in terms of a retrieve relation R together 
with two identities id between the inputs and outputs (see Figure 1(a)). 
In order to allow the types of inputs and outputs to change, 10 re- 
finement replaces the identities id with arbitrary relations IT and OT 
between the input and output elements respectively. Thus IT and OT 
are essentially retrieve relations between the inputs and outputs, hence 
allowing these to change under a refinement in a similar way to changing 
the state space (see Figure 1(b)). 

It is necessary to impose some conditions on IT and OT. The first 
is that we require that IT and OT are total on the abstract input and 
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{a) Standard rvfinamant of AOp by COp (b) lO raflnarnant of AOp by COp 



Figure 1 Standard and 10 refinement of operations 



output types. This ensures that every abstract input can be used in 
the concrete operation. The second is that OT must be injective. This 
means that different abstract ( “original” ) outputs can be distinguished in 
the concrete cases because their concrete representations will be different 
as well. 

IT and OT are written as schemas and called input and output trans- 
formers. An input transformer for a schema is an operation whose out- 
puts exactly match the schema’s inputs, and whose signature is made up 
of input- and output components only; similarly for output transformers. 
These are applied to the abstract and concrete operations using piping 
(;»). To do so we use an overlining operator, which extends componen- 
twise to signatures and schemas: x? = x!,a;! = xl. Thus IT denotes the 
schema where all inputs become outputs with the same basename, and 
all outputs inputs. 

For an 10 refinement of one abstract operation into one concrete op- 
eration the following definition is used. 

Definition 4 10 refinement for a single operation 
Let IT be an input transformer for COp which is total on the abstract 
inputs. Let OT be a total injective output transformer for AOp. The re- 
trieve relation R defines an 10 refinement if (initialisation is as before): 

Applicability: V A. State; C. State • preiJT » AOp) pre COp 

Correctness: 

\/ A. State; C. State; C. State' • 

R A {IT > COp) ^ 3 A. State' • R' A {AOp :$> OT) 
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The correctness criteria requires that COp with the input transformation 
should produce a result related by R and the output transformation to one 
that A Op could have produced. 



10 refinement allows inputs and outputs to be refined in a controlled 
manner. Controlled because since inputs and outputs are observable we 
must be able to reconstruct the original behaviour from a concrete re- 
finement. This reconstruction is achieved by using the input and output 
transformers which act as wrappers to a concrete operation, converting 
abstract inputs to concrete ones and similarly for the output. 




5.2. APPLYING lO TRANSFORMATIONS TO 
ACTION REFINEMENT 

10 refinement is a mechanism to refine the inputs/outputs of one ab- 
stract operation into one concrete operation. To apply it fully to action 
refinements we need to be able to spread the inputs/outputs throughout 
a sequence of concrete operations. Because of this there will not neces- 
sarily be a 1-1 mapping between the number of abstract inputs/outputs 
and the number of concrete inputs/outputs. 

The principal hurdle to overcome is how to spread the abstract in- 
puts/outputs throughout a sequence of concrete operations. To solve 
this problem we will generalise 10 refinement slightly along the follow- 
ing lines. 10 refinement is defined as a condition between one abstract 
and one concrete operation, because of that we used a simple transformer 
IT. In order to decompose one abstract operation into a sequence of con- 
crete operations we need to use a mapping between an abstract input 
and a sequence of concrete inputs representing the inputs needed in the 
decomposition. Therefore we will generalise our transformers IT and 
OT to produce a sequence of inputs and outputs instead of just one. 

For example, for the Passwd operation and its decomposition, the 
input transformer we use is the following. 
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IT 

pin? : N X N X N X N 
d! : seq4 N 

pinl = {d\.l,d\.2,d\.3,d\A) 



This takes in a single input pinl for the abstract operation Passwd and 
maps it to a sequence for use by the concrete operations. The concrete 
operations then use this sequence one by one. Therefore the abstract 
input pinl has been decomposed and spread throughout the concrete 
sequence as desired. The input and output transformer machinery is 
necessary in order that we can express the intuitive requirements for- 
mally in the schema calculus. There are no outputs in this particular 
example so the output transformer is the identity. We then apply the 
ideas from 10 refinement to the definition of action refinement, this re- 
sults in correctness criteria such as 

{IT S> {First[d\.l/d7] ^ Second[d\.2/ d?]^ 

Third[d\.3/d7] g Fourth[d\A/d?])) A R 
<==> 3 Cashpoint. State' • R' A Passwd 

The substitutions, e.g. [d!.l/d?], are used in order to restore the 
distinction between the individual inputs. Such substitutions allow us 
to describe the process of consuming the inputs one by one explicitly in 
the operations. This correctness condition thus asks that with the input 
wrapper IT the concrete sequence is a refinement of Passwd. 

We now consider the general case of a decomposition of A Op into 
COpi § C0p2- The general formalisation combines the three conditions 
needed for a action refinement of AOp into COpi § C0p2 with the use of 
input and output transformers from 10 refinement. The refinement will 
be defined by three parts: a retrieve relation between the state spaces to- 
gether with transformers IT and OT which map abstract inputs/outputs 
to a sequence of concrete inputs/outputs. We can now combine action 
refinement (definition 3) with 10 refinement (definition 4) to produce 
the general conditions for action refinement with 10 transformations. 

The following definition expresses the refinement of AOp into a fixed 
sequence COpi § C0p2- In fact explicit substitutions (as in First above) 
are only necessary when the decomposition of AOp involves more than 
one occurrence of the same input or output parameter names in the 
concrete operations. If COpi and C0p2 are distinct operations with 
distinct parameter names then the formalisation is simplified by the 
omission of the substitutions. 
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Definition 5 Non-atomic refinement with 10 transformations 
Let IT he an input transformer for COpi § COp 2 which is total on the 
abstract inputs. Let OT be a total injective output transformer for AOp. 
The retrieve relation R defines a action 10 refinement if: 

y A. STATE’ C. STATE’, C .StATE' • 

{IT » COpi § COp2) AR=^3 A. State' • R' A {AOp OT) 
V A. State’, C .State • pre{IT 2> AOp) A R pre COpi 
y A. State; C. State • 

pre{IT 3> AOp) A R A {IT 3> COpi) <=> pre COp 2 

The conditions in full for the Passwd operation then become: 

{IT > {First[d\.l/ dl]% Second[d\.2l dl]% 

Third[d\.Z/dl] % Fourth[d\.Aldl])) A R 
4=^ 3 Cashpoint. State' • R' A Passwd 

pre(/T 2> Passwd) A R First 

pre(/T 3> Passwd) A R A {IT 3> First[d\.l/ dl]) Second 

pre(/T ^ Passwd) A R 

A{IT > First[d\.\/dl]%Second[d\.2/dl]) 
pre Third 

pre(/T ':$> Passwd) A R 

A{IT » First[d\.l/ dl]% Second[d\.2/ dl] % Third[d\.^l dl]) 
pre Fourth 

which are easily verified. Therefore we have done what we set out to 
achieve. That is, define a set of action refinement rules which are a 
generalisation of standard refinement but allow the full decomposition 
of operations including inputs and outputs. 

6. CONCLUSIONS 

In this paper we have looked at how we can change the granularity of 
both objects and operations in an Object-Z refinement step. To change 
the granularity of objects we view refinement as refining the main class 
of the specification under consideration. By interpreting the state spaces 
and retrieve relation appropriately in the presence of object instantiation 
we can refine a single class into a number of communicating classes. 

To change the granularity of operations we dispensed with the re- 
quirement that every concrete operation corresponds to an abstract one. 
This enabled quite general refinements to be derived. To do so we ap- 
plied the theory of 10 refinement which extends standard refinement by 
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allowing the retrieve relation to be extended to input and output types 
in addition to relating the state spaces. 
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E-SPEAK: THE TECHNOLOGY FOR 
UBIQUITOUS E-SERVICES 



Alan H. Karp 
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Abstract 

Today, setting up a service to be used over the Internet is difficult, 
special-case work. Part of the difficulty is that each provider of such 
a service addresses a common set of problems in a proprietary way. 
E-speak solves the problems of naming, describing, managing, and con- 
trolling access in a manner that makes it easier and safer to allow remote 
access. With e-speak, we can think of all applications as e-services that 
we can enlist to solve our problems. 

E-speak is the open-source software platform for creating, composing, 
mediating, managing, and accessing Internet-based e-services. With e- 
speak we can more easily build a world of universal e-services that can 
be accessed intuitively using a wide array of devices and platforms, 
from personal digital assistants, to PCs, information appliances, and 
supercomputers. With e-speak these e-services can interact with each 
other in order to advertise capabilities, discover other e-services, and 
ally with each other to offer new functionality, even negotiate to broker, 
bill, manage, and monitor each other - all in a dynamic, ad hoc, yet 
secure manner. 

This talk will describe the requirements that led to the various fea- 
tures of the e-speak architecture as well as its key abstrax:tions and 
innovations. 
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Abstract We propose a new synchronous language called Behavior Expression, its seman- 
tics and compilation mechanism. We also present Omdd as intermediate code 
for its compilation. Dependency cycle, determinism and composability can be 
checked directly by analyzing Omdds. Consequently, it allows partial com- 
pilation and automatic distribution. Based on these benefits, we propose a new 
methodology for the development of real-time distributed systems by integrating 
behavior expression into Uml. 

Keywords: Behavior expression, Omdd, real-time system, distributed system 

Introduction 

The Unified Modeling Language (Uml) [8] has rapidly become a hot topic 
of the software design community. It is composed of different kinds of di- 
agrams which describe different views. These views represent our comple- 
mentary and orthogonal cognitions of the desired system. By specifying one 
cognition in one diagram, Uml eases system modeling, and induces less mis- 
understandings. Having a set of benefits, it becomes a standard framework for 
object-oriented methodologies. 

However, when it comes to consistency check for Uml, or formal verifi- 
cation, or code generation etc., it is somehow hard to grasp a uniform and 
mathematically well-founded semantics from these various different diagrams. 
And without a formal semantics, formal verification becomes a hard work. 

Meanwhile, the concept of synchronous programming [2] has been pro- 
posed and widely accepted in the development of real-time systems, circuits, 
and embedded systems. Based on their mathematical foundation, synchronous 
languages have strict semantics and efficient approaches for their compilation 
and optimization [5, 1, 3]. Formal techniques for verification and validation 
have also been proposed. 
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Our aim in this paper is to take advantage of the rich background of syn- 
chronous model and Uml by providing a new synchronous language called 
Be (Behavior Expression) and a new methodology for the development of 
real-time distributed systems. Thanks to the flexibility of Be, we can easily 
integrate it into UML. And with this integration, we have the benefits of easy 
system modeling (from Uml), automatic code generation and system distribu- 
tion (from Be) at the same time. 

We will present the syntax and semantics of Be in section 1 and 2. Then 
we will provide a mechanism of compilation in section 3. In section 5, we will 
present Omdd as intermediate code for compilation. Partial compilation and 
automatic system distribution are concisely sketched in section 6 and 7. At 
last, we discuss the integration of Be into UML in section 8. 

1. SYNTAX OF BEHAVIOR EXPRESSION 

1.1. PRINCIPLES OF SYNCHRONOUS 
PROGRAMMING 

In the concept of synchronous programming, we assume a real-time system 
reacts according to its environment step by step. Suppose the system has data 
elements a;i, X 2 , • ■ ■ , then its behavior may be described as Figure 1. At 
instant 0, the values represent the initialization of the system. At each instant 
i > 0, the system generates new values for these data elements according to 
the environment and previous state. A data element may have no value at some 
instants (e.g. at instant 2). 



*1 *3 *3 *4 

instant 0 — 1 — 3 E ?- 

instant 1 —3 — 3 — 3 — f 

instant 2 —5 — A f 6- 

instant 3 — ? — 5 — 6 3- 



Figure 1 Principles of synchronous programming 



For a certain instant i > 0, denote the current value of x with x.set, and 
its previous value with x.get. Then, the principles of synchronous languages 
are to describe how Xi.set can be calculated from xi.get and inputs for every 
instant. In the next sections we will propose a new language called Behavior 
Expression (Be). 
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1.2. GRAMMAR 

The behavior of an object is specified by a Behavior Expression E, whose 
grammar is: 



integer 
true\false 
x.get 
x.set 

fa{e, • • • ,e) 
fb{e, • • • ,e) 

Figure 2 Grammar of behavior expression 



//event 

/integer constant 
//boolean constant 



// fa is an arithmetic function 
// fb is a boolean function 



C ::= 



x.get(e) 
x.set{e) 
-^x.get(e) 
->x.set{e) 
C AC 



E ::= 



x.set{e) 
Ch E 
E\\E 
EVE 



In this figure, e is an expression of a certain type (integer, boolean, event 
etc.). A data element x has two channels: x.get and x.set, they can be used in 
e (like a variable). C is a condition* used to trigger a Be E. 

1.3. COMMON SENSE 

Each Be E describes a behavior, or, vaguely speaking, a “task” we have to 
do. We have four ways to specify it: 

■ Assign a set-channel with a value (x.set{e)). 

■ Divide the “task” into several parts, each corresponds to a “sub-task”. 
Specify each sub-task with a Be, and then compose them (E || E'). 

■ The “task” can be done in some different ways. Each is specified by a 
Be, and then make a choice between them {E V E'). 

■ The “task” will be performed only on some condition C, it is specified 
asC\- E. 

1.4. EXTENSIONS 

■ Inputs 

Input events or values are necessary to control a system interactively. 
They are represented by parameters. A parameter p has only a channel 
p.get whose value comes from the environment or user input. 

■ Guards 



*It resembles boolean expression, x.get(e) can be regarded as “if the value of x.get equals e”. A careful 
reader may ask why we do not use disjunction in its definition, and why we use ->x.set{e) and ->x.get{e) 
instead of -»C. The reasons are: 1/ The restriction of C in this form avoids transforming a boolean expres- 
sion in Disjunctive Normal Form (which is NP-complete) while constructing Omdds. 2/ This is already 
enough for specification since pure boolean expression can be used as a guard (cf. section 1.4). 
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Suppose 6 is a boolean expression. b\~ E is introduced for convenience: 
b\- E = {^.set{b) II ^.set{true) h E) 

■ Initial state 

We can also provide the initial state for a Be as shown in the following 
syntax. 

E ••• /* defined in 1.2 */ 

\ b\- E /* guard extension */ 

I E “initial” I /* initialization */ 

I ::= x.set{e) 

I I x.set{e) 

■ Name 

We can give a Be a name, and then use the name for clearer representa- 
tion. 

E ::= ••• /* defined above */ 

I name E /* give E a name */ 

I name /* recall a named Be */ 

■ Priority 

p 

We uses Ei\/E 2 to describe a “choice with priority”. When the choice 
is not exclusive, we choose Ei as it has higher priority than E 2 (See 3.3 
for more detail). 



1.5. EXAMPLES 

Example 1 This is a simple example mimicking the function of a clock. It is divided into 
three parts: second, minute and hour. For every instant, the behavior of second is to increase 
by one. 

Es := S. set {{S. get 4- 1) mod 60) initial S.set{0) 

The behavior of minute is to increase by one whenever a new minute passes (S is set to 0), 
or to keep the same value otherwise. 



Em := 



S.set{0) h M.set{{M.get -I- 1) mod 60) 

p 

Y M.set(M.get) 



initial M.set(0) 



Similarly, the behavior of hour is to increase by one whenever a new hour passes ( S and M 
are set to 0 at the same time), or to keep the same value otherwise. 



Eh := 



S.set{0) A M.set{0) h H.set{(H.get 1) mod 24) 

p 

\J H.set(H.get) 



initial H.set{0) 



As a result, the behavior of the total system is the composition of these three: Edock = 

Es II Em II Eh. 
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Example 2 Suppose we have a virtual system with a boolean input C. When C is true, we 
let X increase by 1 and Y be X* 2. Otherwise, we let X decrease by 1 and Y be X 12. Initially, 
X and Y are 0. The behavior expression of this system is: 




X. set{X.get -h 1) 

Y. set{X.set * 2) 
X.set{X.get — 1) 
Yset{X.set/2) 



initial X.set(O), Y.set{Q) 



2. SEMANTICS OF Be 

■ A pre-assignment P of a Be is to associate each get-channel with a value 
in its corresponding domain. 



■ An assignment A of a Be is to associate each set-channel with a value 
in its extended domain^. 



2.1. MAP 

Given a pre-assignment P and an assignment A, we define a map f : E Li 
C — > {T, P, — } corresponding to grammar items illustrated in Figure 2. 

f{x.get{e)) = [x.get == e) 
f{x.set{e)) — {x.set == e) 
fi^C) = ~^f{C) 

/(Cl A C2) = /(Cl) A /(C2) 

/(ChP) = /(C)h/(P) 

/(Pi II P2) = /(Pi) II /(P2) 

/(PlVP2) = /(Pl)V/(P2) 



In addition, -iT = P; -iP = T; A, h, || and V are defined in Figure 3. 




Figure 8 Map definition for A, h, jj, V 



^As stated in section 1.1, a data element may have no value at some instants, this is called absence. We 
extend the domain with an “absent” value “±” denoting its absence. 
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Example 3 As a continuation of Example 2, P = {C.get = true^ X.get = 3, Y.get = 6} 
is a pre-assignment, and A = {X.set = 4, Y.set = 8} is an assignment. Let's demonstrate 



the definition of map step by step: 

f{X.set{X.get + 1)) = {X.set == X.get + 1) = T (1) 

f{Y.set{X.set ♦ 2)) = {Y.set == X.set * 2) = T (2) 

f {C.get {true)) = {C.get == true) =T (3) 

- / X.Set{X.get ~^^)\_rp\\rp_n^ /J\ 

II Y.set{X.set*2) ^ ^ H ^ ^ 



f (C^ge,(,ru.) h ( || J .'" 2 )'* ) ) = ^ 

f {C.get {false)) = {C.get == false 
f(c.get{false)^(^ || ) 

\ \ " V / / 

In (7), we used a trick: for any value F h ? = — . 

2 . 2 . SEMANTICS 

Given a Be a pre-assignment P and an assignment A, A is called a 
solution of E with respect to (w.r.t) P iff: 

■ f{E)=T 

■ for all x.set, if VC h x.set{e) appear in E, f{C) = F, then x.set is 
assigned with J_ in A. 

In Example 3, A is a solution w.r.t P, while A' = {X.set = 4, Y.set = 7} 
is not. 

Given an object whose behavior is described by E with initialization Aq, its 
behavior is the trace: 

Aq,Ai,A2,--- 

where Ai is a solution of E w.r.t Ai-i, i = 1, 2, 3, ■ ■ Note that when shifting 
from instant (? — 1) to i, a data element moves the value in x.set to x.get. 
Which means that Ai-i (together with the input values) is actually the pre- 
assignment for Ai. 

2.3. DETERMINISM 

Given an expression E and an initial state, it is deterministic iff for all i = 

1. 2. 3. • ■ there is only one solution Ai of E w.r.t Ai-i. 



C.getitrxie) h 
V C.get(false) h 



X. set(X.get -I- 1) 

Y. set(X.set * 2) 

X. set{X.get — 1) 

Y. setiX. set/2) 



) = F (6) 

= F I- ? = - (7) 

\ 

= r II - = T ( 8 ) 

/ 
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2.4. COMMENTS 

According to the syntax and semantics, we can see that Be is simply an 
expression that must be satisfied at every instant. It is flexible in the sense 
of “choice” and “activation”. Suppose we have already described two behav- 
iors in Be and E2. Now we have a new system which behaves as Ei on 
condition C\ and as E2 on conditions €2- Then we can easily write the Be 
{Cl h El) V {C2 H E2) for the new system. Some earlier synchronous lan- 
guages [ 2 ] do not share these flexibilities however. 



3. COMPILATION OF Be 
3.1. SIMPLIFYING Be 



Theorem 1 According to the map defined in section 2 . 1 , we can easily prove: 

C^{Ei\\E2) = {C\-Ei)\\{C^E2) 

C^{Ei\/E2) = V(Ch^2) 

Ch(C'hJ52) = {C^C•)^E2 



We simplify a Be by repeatedly substituting the left part of these equations by 
the right part, until for any C \~ E, E set-channel. Such C \~ E is called a 
primitive Be. A simplified Be is then composed of a set of primitive Bes with 
operations V and || . 



Example 4 Let us consider the Be in example 2. After simplification it becomes: 



/ 

V 



3.2. 



C.get{true) h X.set{X.get -h 1) 

II C.get{true) h Y.set(X.set * 2) 
C.get(false) h X.set{X.get — 1) 
II C.getlfalse) h Y. set {X. set/ 2) 



\ 

initial X.set{Q)^ Y.set{0) 

/ 



WELL-FORMED BE 



A simplified Be E is well-formed iff: for all Ei || E2 appears in E, there 
doesn’t exist Ci h xi.set{ei) in Ei and C2 H X2-set{e2) in E2 such that 
xi-set and X2-set are actually the same set-channeP. 

In this paper, we consider only well-formed Be. A Be not well-formed is 
something like a C program with syntax error. 



Theorem 2 A well-formed E is deterministic iff for all Ei V E2 appears 
in E, Cl h xi.set{ei) in Ei and C2 H X2-set{e2) in E2, f{Ci A C2) = F. 
( proof omitted ) 



^This is similar with Signal, we don’t accept (|X := 1 when Ci\X := 2 when C 2 I) in Signal. This 
is to say, if a system 5 is a composition of two sub-systems 51 and 52, then 51 and 52 are supposed to do 
different things. 
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3.3. NON-DETERMINISM 

If a well-formed Be is not deterministic, we do not know which one of E\ or 
E2 should be chosen when C\ and C2 are both true. We will give two remedies 
for this problem. 

■ Using priority 

p 

EiyE 2 is introduced as a “choice with priority”. Whenever we have 
C\ h x\.set{ei) in E\, C2 H X2-set{e2) in E2, C\ and C2 are not 
exclusive, suppose Ci = Ai Cu (cf. its grammar in Figure 2), then 
C 2 H X 2 -set{e 2 ) is substituted by: (where -'(-’C) = C) 



C 2 A ->Cii h X2-set{e2) 

V C 2 A Cn A -‘C 12 ^ X2-set{e2) 

V • • • 

V C 2 A C\\ A • • • A C\^n-i A "^Cin 1“ X2-set{e2) 



■ User indication 

Introduce a new parameter ^ to control the choice between E\ and E 2 '. 
{^.get{true) h Ei) V {^.get{false) h E 2 ). 



Example 5 After this process, the Be in Example 1 is changed to: 



S.set{{S.get 1) mod 60) initial S.set{Qi) 
f S.set{0) h M.set{{M.get + 1) mod 60) 
y V -'iS'.set(O) h M.set{M.get) 

/ 5.set(0) A M.56^(0) h H.set{{H.get + 1) mod 24) 

I V -^S.set{0) h H.set(H.get) 

V V S.set{0) A -iM.sei(O) h H.set(H.get) 



^ initii 



initial M.set{0) 



initial H.set{0) 



3.4. ORGANIZING Be 

Both C h x.set{e) and Vi Ci h x.set(ei) are called a single choices on x, 
denoted by Vx- re-organize a Be to “compositions of single choices”, 

that is, of the form || ■ Vxi- 
For any minimal occurrence of: 



( II i^xi) V ( II j^yj) 



(9) 



we can re-write it as: 



II (Vxi) V (Vyj) where xi = yj 
11 Vji ^yj : xi = yj 

II ^yj ^xi : xi = yj 



(10) 




Behavior Expression and OMDD 293 



Theorem 3 On condition of well-formed deterministic Be, (9)-( 10), 

By repeatedly applying this rule, we can gain our aim. 

Example 6 The Be in example 4 is a well-formed deterministic Be. After re-organization, 
it becomes: 

( / C.get{true) h X.set{X.get +1) \ 

I V C.getlfalse) h X.set{X.get — 1) J 
II I C.getitrue) h Y.set{X.set ♦ 2) \ 

^ Y V C.get(false) h Y. set {X. set/ 2) J 

3.5. CODE GENERATION 

■ Generating SIGNAL code 

Signal was proposed in [2] and its compilation has already been im- 
plemented. An advantage of generating Signal code is to re-use the ex- 
isting clock calculus and causality analysis procedures of Signal com- 
piler. 

After the re-organization, a Be looks like a Signal process. A “sin- 
gle choice” is an equation in Signal (probably) with “default”, and 
composition of “single choices” is just like composition of equations in 
Signal. However, if we re-write a Be in Signal directly like this, we 
will usually get clock constraints. The main reasons are: 

- X and XS (correspond to X.set and X.get in this paper) have the 
same clock in Signal. 

- for an equation X := f{X\, • • • , X„), X, Xi, ■ ■ •, have the 
same clock. 

However, in Be, we do not have these constraints. A solution is to create 
a set of new variables in Signal carrying the wanted values with the 
“most frequent” clock. As these variables have the same clock, they can 
be used in every expression as we like. More details are omitted in this 
paper, please refer to appendix for examples. 

A prototype of translating a Be into Signal is already implemented. 
The generated signal processes of Example 1 and 2 are provided in the 
appendix. 

■ Using Omdd as intermediate code 
This will be presented in section 5. 



\ 

initial X.set{0)^ Y.set{0) 

/ 
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4. DEPENDENCY AND VIRTUAL ORDER 

The compilation of synchronous languages usually requires dependency 
(causality) analysis [1,5]. Let’s consider the Be in example 2, we must know 
the value of X.set and C.get before the calculation of Y.set, so we have de- 
pendency X.set Y.set and C.get Y.set. Surely, dependencies cannot 
have cycle. So there exists a total order which covers all the dependencies. We 
call it virtual order. Figure 4 gives an algorithm to calculate a virtual order 
from a re-organized Be = || 



Let Si be the set of channels other than Xi.set appearing in V^i 

Let B be the set of all get-channels of E 

Let AT = 0 //channels already ordered 

Let = 0 //empty virtual order 

while (E is not empty) { 

if 3i such that Si C B then { 

append a random order of (5i \ A^) to V 
append Xj. 5 ef to V 
N = N U Si U {xi.set} 

B = B U {xi.set} 
remove from E 
} 

else report error // due to dependency cycle 

} 

return V 



Figure 4 Algorithm of virtual order 



Example 7 The virtual orders of the Be in Example 5 is: 

< S.get, S.set^ M.get, M.set, H.get^ H.set > 
and that of Example 6 is: 

< C.get, X. get jX. set j Y.set > 



5. OMDD 

Binary Decision Diagram (BDD) [6, 9] has been proposed as a date struc- 
ture to represent boolean functions. Reduced ordered BDD (ROBDD) [7] in- 
troduces further restrictions on the order of decision variables in the graph. 

In this section, we will present a date structure called Ordered Multiple De- 
cision Diagram (Omdd) on a similar principle as an intermediate code for the 
compilation of behavior expressions. 

5.1. DEFINITION 

Given the channels totally ordered, we define Omdd as: 

1 A node {x.set, x.set{e)) is an Omdd 
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2 Given a set of Omdds Mi, M 2 , • • • , M„, the structure of figure 5 is also 
an Omdd, where: 

(a) C is a channel 

(b) if C is a set-channel, A is an (possibly empty) action C{e). {A 
must be empty if C is not a set-channel. ) 

(c) Li are mutually exclusive restrictions of the value of channel C 

(d) for any channel C in Mi, M 2 , ■ • • , M„, C < C 



(C, A) 




M, M, M„ 

I z n 



Figure 5 Base structure of OMDD 

We are somehow indifferent to the strict form of the “restriction” of values. 
We can use “c”, ‘V c” (c is a constant like 0, true, etc.), “any” or even sub- 
ranges such as [3, - 1 - 00 ). What’s important is to be able to perform the union, 
intersection, subtraction of “restrictions”. 

The structure in figure 5 means, we will do action A (if there is one) when 
arriving at node {C, A). Then we check the value of C, if it satisfies Lk, then 
we leave for Mfc. So, code generation from OMDD is very simple. 

5.2. CODE GENERATION FROM Omdd 

1) For a leaf node N = {x.set, x.set{e)), it is translated to a procedure: 

PJV(){x.sef = e; } 

2) For an Omdd M as Figure 5, it is translated to a procedme: 

P_M(){ 

A; // if A is empty, we do nothing here, 
if (C is in L\) then P_Mi(); 
else if (C is in L 2 ) then P_M 2 (): 

else if (C is in L„) then P_Mn(); 



} 
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5.3. CONSTRUCTING Omdd 

In this subsection, we will discuss the construction of Omdd for a Be. Af- 
ter the simplification, determinism check, and re-organization, a Be can be 
described as: 



E = II iEi 


(11) 


Ei = WjEij 


(12) 


Eij = ^kEijki^ijk) Xi.setifiij) 


(13) 


Eij 




Without loss of generality, we suppose Ciji < Cij2 < • • • 
the Omdd of Eij is'*: 


< Cijn- Then 


{Cijn, (l))^{xi.set, Xi.set{e'ij)) 




Ei = VjEij 




The Omdd Mj of Ei can be obtained from My by choice function given 



in Figure 6. 



■ ^ = II iEi 

The Omdd M of ^ is obtained from Mi by comp function illustrated in 
Figure 7. 



5.4. EXAMPLES 

Example 8 Let us consider the expression in Example 6, and use the virtual order in example 
7, the four base Omdd^ are: 

{C.get, 0)-4(Xsei, X.set{X.get + 1)) 
(C.get,(i)-^{X.setyX.set{X.get — 1)) 

{C.get, 0)-^(y.5et, Y.set{X.set * 2)) 

{C.getj il})-^-{Y.sety Y. set {X. set/ 2)) 

When they are bound together, the result OMDD and its corresponding code are presented in 
Figure 8. 



careful reader may ask how about if eijk is not a constant. This is not a fatal problem, however. We can 
simply substitute Cijkicijk) by ^.set{true), and compose Eij with ^.set(Cijk == ^ijk)' 
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OMDD choice (OMDD ml, OMDD m2) 

{ 

if (ml.c==m2.c) 

{ 

if (ml. a is not empty && m2. a is not empty) then 
raise error; // nondeterministic 

else 

{ 

if (ml has no subtree) raise error; // nondeterministic 
if (m2 has no subtree) raise error; // nondeterministic 

suppose the subtrees of ml are mil, ml2, ... min with label 111, ... lln; 

suppose the subtrees of m2 are m21, m22, . . . m2m with label 121, ... 12m; 

NODE tmp; 
tmp . c=ml . c ; 

tmp.a=union of ml. a and m2. a // the non-empty action if there is one 
ll=union of 111 , 112 , . . . , lln; 

12=union of 121,122,...,12m; 

for (i=l; i<=n; i++) add mli as a subtree of tmp with label lli\12; 

for ( j=l; j<=m; j++) add m2 j as a subtree of tmp with label 12j\ll; 

for (i = l ; i<=n; i++) for ( j=l ; j<=m; j++) 

add choice (mli, m2 j ) as a subtree of tmp with label 12j"lli; 
return tmp; 

} 

} 

else if (ml.c<m2.c) 

{ 

NODE tmp; 

tmp . c=ml . c ; tmp . a = empty ; 

add subtree m2 to tmp with lable "any"; 

return choice (ml , tmp) ; 

} 

else 

{ 

NODE tmp; 

tmp . c=m2 . c ; tmp . a=empty ; 

add subtree ml to tmp with lable "any"; 

return choice (tmp, m2) ; 

} 



Figure 6 Choice operation for two Omdds 
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OMDD comp(OMDD ml, OMDD m2) 

{ 

if (ml . c==m2 . c) 

{ 

if (ml. a is not empty && m2.a is not empty) then 
raise error; //OMDDs can not be composed 

else 

{ if (ml has no subtree) { 

m2.a=ml.a; //ml. a is not empty because it is a leaf node 
return m2 ; 

} 

if (m2 has no subtree) { 

ml.a=m2.a; //m2.a is not empty because it is a leaf node 
return ml; 

} 

suppose the subtrees of ml are mil, ml2, . . . min with label 111, ... lln; 

suppose the subtrees of m2 are m21, m2 2, ... m2m with label 121, ... 12m; 

NODE tmp; 
tmp . c=ml . c ; 

tmp.a=union of ml. a and m2. a // the non-empty action if there is one 
ll=union of 111 , 112 , . . . , lln; 

12=union of 121,122,...,12m; 

for ( i=l ; i<=n; i++) add mli as a subtree of tmp with label lli\12; 

for ( j =1 ; j<=m; j++) add m2 j as a subtree of tmp with label 12j\ll; 

for (i=l ; i<=n; i++) for ( j=l ; j<=m; j++) 

add comp (mli , m2 j ) as a subtree of tmp with label 12j^lli; 
return tmp; 

} 

} 

else if (ml.c<m2.c) 

{ 

NODE tmp; 

tmp . c=ml . c ; tmp . a = empty ; 

add subtree m2 to tmp with lable "any"; 

return comp (ml , tmp) ; 

} 

else II m2 . c < ml . c 

{ 

NODE tmp; 

tmp . c=m2 . c ; tmp . a=empty ; 

add subtree ml to tmp with lable "any"; 
return comp ( tmp , m2 ) ; 

} 

} 



Figure 1 Composition operation for two Omdds 
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if C.get==true then 
{X.set=X.get+l;Y.set=X.set*2;} 
else if C.get==false then 
{X.set=X.get-l;Y.set=X.set/2;} 



(C.get,0) 




(X.set, X.set(X.get+l)) 
any 

(Y.set, Y.set(X.set*2)) 



(X.set, X.set(X.get.l)) 
any 

(Y.set, Y.sct(X.set/2)) 



Figure 8 Bound OMDD and generated code of Example 8 



Example 9 Let us consider the Be in Example 5, and virtual order in example 7, the base 
OmdD5, the bound Omdd, and the generated code are: 

{S.set, S.set{S.get + 1 mod 60)) 

(S.setj ih)-^{M.set, M .set{M .get + 1 mod 60)) 

{S.set^ 9)^^{M.set, M .set {M .get)) 

{S.set, 0)-^(M.sef , 0)-^(ff.5ef, H.set{H.get + 1 mod 24)) 

{S.set, ^)^{H.set, H.set{H.get)) 

{S.set, ^)-^{M.set, ^)^{H.set, H.set{H.get)) 



( S.set, S.set(S.get+l mod 60) ) 




(H.set, H.set(H.get+l mod 24) ) (H.set, H.set(H.get) ) (H.set, H.set(H.get) ) 



S.set=S.get+l mod 60; 
if S.set==0 then 
{ M.set=M.get+l mod 60; 
if M.set==0 then H.set=H.get+l mod 24; 
else if M.set!=0 then H.set=H.get; 

} 

else if S.set!=0 then 
{ M.set=M.get; 

H.set=H.get; 

} 



6. PARTIAL COMPILATION 

In section 3, we presented the compilation of Be by way of SIGNAL. One 
benefit of this compilation is the re-use of Signal compiler. In section 5, 
we presented Omdd as intermediate code. Besides the efficiency of generated 
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code, this has two other advantages: partial compilation and automatic system 
distribution. We discuss partial compilation in this section. 

Suppose we have a system E consisting of sub-systems Ei with || and 
V operations. In section 3 and 5, we compile E directly. So, if there is a 
sub-system reused several times, it will be integrated and compiled several 
times. This is not satisfying when re-use is highly demanded. Can we com- 
pile sub-systems Ei so that the compilation of E is simply an integration of 
pre-compiled codes? Unfortunately, it is shown in [4] that, brute-force pre- 
compilation and their simple combination have some problems. 

Actually, in order for partial compilation, we must be able to do following 
things /rom the pre-compiled codes for system integration: 

1 Check if the integration of sub-systems will introduce dependency cy- 
cles. 

2 Check the composability of subsystems. For example, if two sub-systems 
assign different values to the same channel on the same condition, they 
can not be composed. 

3 Check the determinism of the integrated system. 

These are easy when Omdd is used as intermediate codes. For 1, we need 
only to check if their virtual orders are conflict. And the algorithms given in 
Figure 6 and 7 contain already check 2 and 3. 

Actually, in the total compilation presented in section 3 and 5, we have 
already checked these properties from Be: virtual order is generated, compos- 
ability and determinism are already assured. So, when constructing OMDD, 
they do not need the checks in “choice” and “comp” operation any more. 

This result is satisfying: Partial compilation ensures re-usability. Sub-systems 
and classes can be designed and compiled into Omdds and stored in a library. 
We are able to reuse the compiled Omdds as well as existing classes. This is 
helpful for large-scale systems. 

7. SYSTEM DISTRIBUTION 

Although the concept of synchronous model has been widely accepted, it is 
also argued that, very frequently, real-life architectures do not obey the ideal 
model of perfect synchrony. Consequently, when a synchronous system is 
distributed to several sites with an asynchronous communication, its behavior 
will probably change. 

Fortunately, some technical results on this issue have been presented in [4, 
3]. As an inference of these results, we can safely distribute a synchronous 
system without changing its behavior if the Omdds of sub-systems are all 
sub-trees of the Omdd of the total system. 
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Suppose, for instance, the total system E is composed of sub-systems Ei. 
If for all i, the Omdd of E{ is a subtree of that of E, then we can safely 
distribute Ei into different sites. However, suppose the Omdd of E\ is not a 
sub-tree of that of E, we can find a small E[ (by analyzing Omdds) such that 
the Omdd of {E[ || Ei) is a sub-tree and E has the same behavior when Ei 
is substituted by {E'l || E{). Then we can use {E[ || Ei) instead of Ei in the 
distribution. This is not a magic, essentially, adding E[ to E\ actually means 
adding a protocol of communication. 

8. METHODOLOGY OF DEVELOPMENT 

In this section, we aim to integrate Be into Uml in order to take both the 
advantages of synchronous concept and that of object oriented concept, and 
to present a new methodology of the development for real-time distributed 
systems. 

In this methodology, a class of reactive objects will be represented by a 
graph as : 

Class name 
Interface 

Behavior 

expression 

So, we will use Uml class diagrams and deployment diagrams to describe 
the architecture of the desired system; and use state machines, MSC, and Be 
to define its reactive behavior. 

In the beginning, we may have only vague ideas and the system is highly 
abstracted. Thanks to the flexibility of Be, it allows us to specify premature 
systems when we have only vague ideas in early stages. As development pro- 
ceeds through the life cycle, these high-level abstract elements are expanded 
into low-level concrete elements; and the maturity level of element increases 
as it is corrected, polished, and optimized. 

The choice of using state-machine, MSC or Be depends on the characteristic 
of the described object. Although Be fits the specification for lots of objects, 
state-machine may fit better for some other objects. But, by the end of the 
design process, other diagrams are translated to behavior expressions automat- 
ically. For example, we have already developed a prototype to translate state 
machines into Be. At the last stage, we will use the techniques stated in pre- 
vious sections to simplify the Be, check and enforce determinism, re-organize 
it, and at last, Omdds are constructed, codes are generated and distributed 
correctly over different sites. 

Let us consider a simple example: a clock with time-set operation. It has 
three buttons. “Mode” button (denoted with M_b) is used to change the mode 
of the clock to vision-mode, set-minute-mode, set-hour-mode and again vision- 
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mode. An “Add” button and a “Sub” button (denoted with +_b and -_b re- 
spectively) are used to increase or decrease the value when the clock is in 
set-minute-mode or set-hour-mode. Pressing “Add” button and “Sub” button 
when the clock is in vision-mode will do nothing. 

After analysis of this requirement, we can decompose the system into three 
parts. One is to mn the time normally in vision-mode as stated in the example 
1, one is to manipulate the mode, and the other is to increase or decrease the 
value of minute or hour when necessary. So this system can be drawn as a class 
diagram in the following figure. 




9. CONCLUSION 

In this paper, we proposed a new synchronous language called Be to de- 
scribe behavior of reactive objects. Essentially, it is simply an expression that 
must be satisfied at every instant. It is a declarative language and it is flexible in 
the sense of activation and choice. As a result, it is suitable even in early stages 
of development when we have only vague cognition of the desired system. 

Based on its mathematical semantics and mathematical form, we presented 
a set of mechanisms to simplify Be; to remove non-determinism by priority or 
user indication; to re-organize well-formed deterministic Be; and to compile 
Be by way of Signal. We provided also an approach to build a total order of 
channels covering all the dependencies. 

We also proposed Omdd as an inter-mediate structure for the compilation 
of Be. Constructing OMDD from Be and generating code from OMDD are 
presented. The “choice” and “comp” operations on Omdds allow partial com- 
pilation and facilitate automatic system distribution. 

By integrating Be into Uml, we get an ideal approach for the development 
of real-time distributed systems. We have at the same time the advantages of 
easy system modeling and formal techniques. We use Uml class diagram and 














Behavior Expression and OMDD 303 



deployment diagram to describe the architecture; use state machine, MSC, and 
Be to define the behavior. State-machines and MSCs can be translated into Be 
to take advantages of partial compilation and system distribution mechanism. 
Till now, a prototype of translating from state-machines into Be, and another 
from Be into Signal have been implemented with satisfying results. 

Appendix: Signal processes for Example 1 and 2 



process result = 

( ? 

! integer S; 

integer M; 
integer H 

) 

( 1 sys : = 1 

I S_val := S default (S_val$ init 0) when "sys 
I S_pre := (S_val$ init 0) when "sys 
I S_pre "= sys "= S_val 

I M_val := M default (M_val$ init 0) when "sys 
I M_pre := (M_val$ init 0) when "sys 
I M_pre "= sys "= M_val 

I H_val := H default (H_val$ init 0) when "sys 
I H_pre := (H_val$ init 0) when "sys 
I H_pre "= sys "= H_val 
1 S := ( (S_pre+1) modulo 60) when "sys 
I M := {(M_pre+1) modulo 60) when S_val=0 when "S 
default M__pre when "sys 

I H := ((H_pre+1) modulo 24) when S_val=0 when M_val=0 when "M when "S 
default H_pre when "sys 

I ) 



Figure A.l The SIGNAL process of Example 1 



process result = 

( ? boolean C 

! integer X; 

integer Y 

) 

( 1 sys : = 1 
I sys "= C 

1 X_val := X default (X_val$ init 0) when "sys 
I X_pre := (X_val$ init 0) when "sys 
I X_pre "= sys "= X_val 

I Y_val := Y default (Y_val$ init 0) when "sys 
I sys "= Y_val 

I C_val := C default C_val$ when "sys 
I sys "= C_val 

I X := (X__pre+1) when C_val=true when "C 

default (X_pre-1) when C_val=false when "C 
j Y := (X_val*2) when C_val=true when "X when "C 

default (X_val/2) when C_val=false when "X when "C 

I ) 



Figure A. 2 The SIGNAL process of Example 2 
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Abstract This paper presents a logic, called BOTL (Object-Based Temporal Logic), that 
facilitates the specification of dynamic and static properties of object-based sys- 
tems. The logic is based on the branching temporal logic CTL and the Object 
Constraint Language (OCL), an optional part of the UML standard for expressing 
static properties over class diagrams. The formal semantics of BOTL is defined 
in terms of a general operational model that is aimed to be applicable to a wide 
range of object-oriented languages. A mapping of a large fragment of OCL onto 
BOTL is defined, thus providing a formal semantics to OCL. 



Keywords: formal verification. Object Constraint Language (OCL), object-based system, 

property specification, temporal logic. 

1. INTRODUCTION 

Due to the ever increasing complexity of forthcoming systems, attempts to 
assess their correctness by engineering “rules of thumb” do not work: they 
easily lead to wrong conclusions and may cause costly redesigns. Instead, a 
systematic and rigorous method for checking their correctness is needed. For 
the specification and verification of reactive systems, the use of temporal log- 
ics has been thoroughly investigated. The availability of software tools that 
support the automatic verification of systems with respect to logical formu- 
lae has become popular and very successful. This applies in particular to the 
model checking approach [7, 8]. For object-oriented systems, however, such 
automated verification techniques have received scant attention. 

In our project we aim at applying the model checking approach to object- 
oriented systems. As a first step, this paper presents a temporal logic, referred to 
as BOTL, that is suited for specifying static and dynamic properties of object- 
based systems. The dynamic properties are related to the behaviour of the 
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system when time evolves, while the static properties refer to the relations 
between syntactical entities such as classes. The logic is an object-based exten- 
sion of the branching temporal logic CTL [6], a formalism for which efficient 
model checking algorithms and tools do exist. The object-based ingredients 
in our logic are largely inspired by the Object Constraint Language (OCL) 
[17, 22, 23], an optional part of the Unified Modeling Language (UML) [5, 20] 
standard which allows expressing static properties over class diagrams in a tex- 
tual way. The precise relationship with OCL is defined by means of a mapping 
of a large fragment of OCL onto BOTL. 

The semantics of the logic is defined in terms of a general operational model 
that is aimed to be applicable to a rather wide range of object-oriented program- 
ming languages. The operational model is a Kripke structure, in which states 
are equipped with information concerning the status of objects and method in- 
vocations. The mapping of BOTL onto these Kripke structures is defined in a 
formal, rigorous way. We believe that such a formal approach is indispensable 
for the construction of reliable software tools such as model checkers. Besides, 
the semantics of BOTL together with the aforementioned translation of OCL 
provides & formal semantics of OCL. This approach resolves several ambigu- 
ities and unclarities in OCL that have been recently reported [10]. See also 
the related work section below for other formalizations of OCL. Our proposal 
covers a rather large fragment of OCL including, amongst others, invariants, 
pre- and postconditions, navigations and iterations. 

Object-based systems. In this paper we confine ourselves to object-based 
systems, i.e., object-oriented systems in which inheritance and subtyping are 
not (yet) considered. Object-based systems are composed by objects. An object 
contains internal data that can only be accessed from the outside by invoking 
one of the object’s methods. Objects run concurrently and communicate by 
means of message passing; i.e., an object that invokes a method (of another 
object) has to wait until the method has returned its result. Objects are dynamic 
and can be created in arbitrary numbers during the computation. On the static 
level, the corresponding notion is that of a class. A class is a template for 
the creation of its instances, i.e., its objects, and specifies the behaviour of the 
objects by describing their state (in terms of so-called attributes) and methods. 

Class diagrams. Classes and their associations are described by class dia- 
grams, a variant of entity-relationship diagrams. A class diagram describes the 
attributes (with their type) and the methods (with their formal parameters) of 
a class. An example class diagram in UML notation is depicted in Figure 1, 
adopted from [23]: boxes represent classes and interconnecting lines denote as- 
sociations. Each direction of an association has a multiplicity and an optional 
name. For instance, a Hotel has a (possibly zero) number of rooms and guests. 
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Figure 1 The Hotel Class Diagram 



Note that class diagrams only address the data aspects of the system, not its dy- 
namic (i.e., process) aspects. The latter aspects are described by other diagrams 
such as UML statecharts. Associations can be traversed — this is referred to 
as navigation — to refer to attributes and methods of a (collection of) object(s) 
in the system, e.g., for object h of class Hotel, the expression {h. guests). name 
refers to the collection of names of the guests of h. Navigations are parsed from 
left to right. 

Object Constraint Language. Constraints over UML class diagrams can 
be described in OCL [17, 22, 23], an optional part of the UML standard. The 
constraints in OCL are invariants (statements that should be valid at any point 
in the computation), and pre- and postconditions (statements about the start and 
end of a method execution). The invariant 

context Hotel invariant 

rooms. guests = guests ' 

states that the collection of guests in the rooms of the hotel should be consistent 
with the collection of guests maintained at the hotel. Clearly, this statement 
is not valid in every state of the system as, for instance, its validity cannot be 
guaranteed while executing a method that changes the number of guests (like 
checking a guest in or out). Pre- and postconditions have a method and a class 
as context. For instance, in 

context Hotel :: checkln(^ : Guest) 

pre not guests-)^ includes (g) (2) 

post guests— ^ size =(guests@pre-^size)-Fl and guests— ^includes (g) 
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the precondition states that the person to be checked in is not a current guest of 
the hotel, while the postcondition states that after checking him in, the number 
of guests has increased by one and the new guest is one of the current guests. The 
©pre-operator refers to the number of guests before the check-in. The standard 
OCL operation size determines the number of elements of a collection. Note 
that invariants and pre/postconditions are safety properties, whereas BOTL also 
allows to express liveness properties. 

Temporal logic. For the specification of the temporal aspects, BOTL is 
based on the branching temporal logic CTL [6]. For CTL efficient model 
checking algorithms and tools already exist. A typical disadvantage of CTL is 
its weakness in expressing fairness. As the object-based ingredients in BOTL 
are quite orthogonal to the temporal aspects, our approach can be applied to other 
(more expressive) temporal logics like CTL* or //-calculus in a straightforward 
manner. 

Related work. Logics for reasoning about object-oriented systems have 
been mainly based on Hoare-style logics that concentrate on verifying pre- and 
postconditions and/or invariants [1,4, 13, 18]. 

Temporal logics for object-oriented systems have been previously defined. 
Amongst others: [3] proposes an algorithmic method to prove properties of con- 
current object-oriented systems expressed in propositional LTL. This method 
combines model checking and tableaux method. [14] presents the specification 
language TROLL for the conceptual modeling of information systems. The for- 
mal semantics of TROLL is given in terms of a translation into a temporal logic. 
[21] proposes, in an axiomatic style, a temporal logic for reasoning about object 
classes and their instances. The logic supports two levels of reasoning: local 
reasoning related to a single object and global reasoning related to a community 
of objects. 

A modal logic for an object calculus is presented in [2]. Verification tech- 
niques based on other techniques have been proposed in [12]. Alternative 
formalisations of OCL have been considered in [9, 11, 19]. To our knowledge, 
this paper presents the first attempt towards embedding OCL in a temporal logic 
setting. 

Organisation of the paper. Section 2 introduces the syntax and semantics 
of BOTL. Section 3 presents the translation of OCL into BOTL. Throughout 
the paper simple examples illustrate the use of the logic. Section 4 presents 
some conclusions and discusses future work. 
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2. THE DEFINITION OF BOTL 

In the following, we assume a set VN ame of variable names', a set MN ame 
of method names, ranged over by M; and a set of class names CName, ranged 
over by C. 

2.1. DATA TYPES AND VALUES 

BOTL expressions rely on a language Type of data types, defined by the 
following grammar: 

r(G Type) ::= void | nat | bool | r list | C ref | C.M ref 

where C G CName and M G MName are arbitrary. The types have the 
following intuitions; 

■ void is the unit type; it only has the trivial value (). 

■ nat is the type of natural numbers. 

■ bool is the type of boolean values tt (true) and ff (false). 

■ T list denotes the type of lists of r, with elements [] (the empty list) 
and h '.'.w (for the list with head element h and tail w). For the sake 
of readability, we will often write lists as comma-separated sequences 
enclosed by square brackets; e.g., 1 :: 2 :: [] is written [1,2], whereas 
[[1], [2]] denotes (1 ::[]):: (2 :: a )::[]. 

■ C ref denotes the type of objects of class C. 

■ C.M ref denotes the type of method occurrences (discussed in more detail 
below) of the method M of class C. 

Let us specify the data values of these types more precisely. Among others we 
will use (references to) objects and events as data values; the latter correspond 
to method occurrences, i.e., invocations of a given method of a given object. 
For this purpose, we introduce the following sets (for all C G CName and 
M G MName); 



OlD^ = {C} X N 

EvT^-^ = OlD^ X {M} X N . 

Thus, object identities ^ G OId^ correspond simply to numbered instances of 
the class C, whereas events G Evt^’^ are numbered instances of the 

method name M, together with an explicit association to the object ^ G OId^ 
executing the method. We also use OId = OId^, ranged over by and 
Evt = Uj;; EVT*"’^, ranged over by p. 
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The combined universe of values will be denoted Val; the set of values of a 
given type r G Type is denoted Val^. We define: 



Val""‘ 

Val^ 

VAL^Mref 



{()} 

N 

{[]} \J {h:\w\h € Val'^, w € Val’^ 
{null} U OId^ 

gyrpC.M 



There exists a large number of standard boolean, arithmetic and list operations 
over these values, which we will use when convenient, without introducing 
them formally. 

Finally, there is a special element J. ^ Val that is used to model the “unde- 
fined” value: we write VaLx = Val U {-L}, etc. All operations are extended 
to X by requiring them to be strict (meaning that if any operand equals X, the 
entire expression equals X). For instance, for lists we have X :: to = X and 
/i :: X = X. 



2.2. SYNTAX OF BOTL 

The syntax of BOTL is built up from two kinds of terms: static expressions 
(for a large part inspired by OCL) and temporal formulae (largely taken from 
CTL). We also use a set of logical variables LogVar. 

e(G ‘S'exp) ::= z \ e.a \ e.owner | e. return | act(e) | u{e, ... ,e) 

I with zi E e from Z2 := e do Z2 := e 

<f>{e Texp) ■■■■= e I -n(/) I V </. I Vz € T : </> I EX0 I E[</>U</)] | A[</>U0] 

where r G Type, a G VName and 2 G LogVar. Apart from this context- 
free grammar, we implicitly rely on a context-sensitive type system, with type 
judgements of the form e G r, to ensure type correctness of the expressions; its 
definition is outside the scope of this paper. We give an informal explanation 
of the BOTL constructs. 



Static expressions. 

■ z G LogVar is a variable, bound to a value elsewhere in the expression 
or formula; 

■ e.a stands for attribute/parameter navigation. The sub-expression e pro- 
vides a reference to an object with an attribute named a or to a method 
occurrence with a formal parameter named a; the navigation expression 




On a Temporal Logic for Object-Based Systems 311 



denotes the value of that attribute/parameter. Navigation is extended nat- 
urally to the case where e is a list of references; the result of e.a is then 
the list of _.a-navigations from the elements of e. 

■ e.owner denotes the object executing the method e. 

■ e. return denotes the return value of the method denoted by e (in case the 
method has indeed returned a value, otherwise the result of the expression 
is undefined; see below). 

■ act(e) expresses that the object or method occurrence denoted by e is 
currently active. An object becomes active when it is created and re- 
mains active ever thereafter, whereas a method becomes active when it 
is invoked and becomes inactive again after it has returned a value. This 
is made more precise in the semantic model; see below. 

■ w(ei, . . . , e„) (n ^ 0) denotes an application of the n-ary operator tu. 
Thus, u; is a syntactic counterpart to the actual boolean, arithmetic and 
list operations defined over our value domain. Possible values for cu 
include at least a conditional expression (“if-then-else”) as well as an 
(overloaded) equality test for all r G Type (where the index r is 
usually omitted). We will use [a;] to indicate the underlying operation of 
which u) is the syntactic representation. 

■ The with-from-do expression is inspired by the iterate feature of OCL 
— which in turn resembles the fold operation of functional programming. 
The expression binds logical variables and can therefore not be seen as an 
ordinary operator. Informally, with z\ G e\ from Z2 := 62 do Z2 := 63 
has the following semantics: first, Z2 is initialised to 62; then 63 is com- 
puted repeatedly and its result is assigned to Z2 while z\ successively takes 
as its value an element of the sequence e\. For instance, the expression 

with z\ G [ 1 , 2 , 3 ] from Z2 := 0 do Z2 := zi -|- Z2 

computes the sum of the elements of the list [ 1 , 2 , 3 ] (= 6). A large group 
of OCL queries can be reduced to iterate expressions (and therefore to 
with-from-do expressions) [22]. 

Temporal expressions. A temporal expression <j) is built by the application 
of classical first order logic operators (- 1 , V etc.) and CTL temporal operators 
(AX, U, etc.); see [6]. The basic predicates are given by boolean expressions in 
5 eip. The temporal operators have the following intuition: 



■ EX</> expresses that there is a next state in which the formula <f> holds. 
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■ E[<^UV’] expresses that there exists a path starting from the current state 
along which xjj holds at a given state, and (f) holds in every state before. 
The special case where (j) equals tt (true) thus stands for the property that 
there is a reachable state where ip holds; this is sometimes denoted Ef ip 
(“potentially eventually ip”). The dual of that is denoted AGip (“invari- 
antly ip”). 

m A[(p\^ 1 p] expresses that along every path starting from the current state, 
Ip holds at a given state and (p holds in every state before. Again, if <p 
equals tt we get the special case AFV> (“V* is inevitable”) and its dual, 
EGV’ (“potentially always ip”). 

Finally, we have universal (and, by duality, existential) quantification: \/z Gr-.cp 
expresses that the formula (p must hold for all instances z of the type r . Note that 
Val^ is infinite for most t 6 Type, making model checking of universally 
quantified formulae impossible. When applying model checking to BOTL, 
therefore, we will have to restrict quantification to bounded cases; for instance, 
all active objects or all integers smaller than a given upper bound. For the 
purpose of this paper, however, we need not make such restrictions. 

In examples, we often omit the type t when it is clear from the context. 
Moreover, apart from the usual abbreviations such as Vz 7 ^ e:<p for Vz: (z 7 ^ 
e) <p, we also use 

■ Vz G act(r): 0forVz G r: act(z) =4- 0, to quantify over all active objects 
or methods in r; 

■ Vz G e.M ref: <p (where e G C ref) for Vz G C.M ref: (z.owner = &)=?► 
4>, to quantify over all method occurrences of a given object. 

Example 2.1. Consider the OCL invariant (1). In BOTL, the same property 
would be expressed by 

AG[Vz G act(Hotel ref) : (Vm G z. checkin ref : -iact(m)) 

sort{flat{z. rooms .guests)) = sort {z. guests)]. ^ ^ 

The function flat flattens nested lists; we need it because z. rooms. guests is a 
list of lists, whereas z. guests is a simple list. The function sort orders lists. 
Note that the condition ->act(m) on the occurrence m of the method checkin 
is essential: during the execution of a checkin, it is not possible to guarantee 
the validity of the invariant. 

As another example, consider the following OCL invariant: 

context Guest invariant 
age > 18 

In BOTL, this will be expressed by: AG[Vz G act(Guest ref) :z.a 5 e> 18] . 
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2.3. THE UNDERLYING OPERATIONAL MODEL 

In the design of our logic we have concentrated on the essential features of 
an object-based system. By this we mean that the logic can only address fea- 
tures, such as object attributes, that are likely to be available in any reasonable 
behavioural model of an object system. Accordingly, we will define the se- 
mantics of BOTL using an operational model that is as “poor” as possible, i.e., 
includes those features addressable by the logic but no more than those. We do 
not go into the question how such a model is to be generated. For instance, the 
degree of parallelism or the way of method invocation is part of the translation 
of an object-oriented language to the model. Any richer kind of model can be 
abstracted to a BOTL model; thus, hopefully, the logic can be used to express 
properties of behaviour models generated by a wide range of formalisms. 

We first need to give the notions of classes, methods and variables more 
substance. Consider the following partial functions; 

VDecl = VName Type 
MDecl = MName — ^ VDecl x Type 
CDecl = CName VDecl x MDecl 

A variable declaration in VDecl is a partial function mapping variable names 
to the corresponding (image) types. MDecl does the same for method names, 
taking into account that these are actually functions with formal parameters and 
a return value. Finally, each D G CDecl is a class declaration mapping class 
names to the corresponding attribute and method declarations. 

Let us assume the class declaration D G CDecl to be given. For any 
class C G dom(D), we denote C.attrs (G VDecl) for its attribute declara- 
tion function, and C.meths (G MDecl) for its method declaration function; 
thus, D{C) = {C.attrs, C.meths). Furthermore, if the class C of a method 
M is clear from the context then we use M.fpars (G VDecl) to denote the 
formal parameters of M and M.retty (G Type) for the return type; hence 
C.meths {M) = {M.fpars, M.retty). 

Ourmodels are Kripke structures, i.e., tuples = (Con/,— >■) where Con/ 

is the set of configurations (or states) over which— C Con/ x Con/ defines 
a transition relation. D G CDecl is the global class declaration, whereas the 
elements of Con/ are pairs of the form {a, 7) where: 

■ (7 G S = OlD VName Val; 

■ 7 G r = Evt ^ (VName Val) x Val^. 

We discuss these briefly. 

■ a describes the currently active objects: for each active object ^ G 
dom(o-), cr(^) denotes the local state of i.e., it records the values 
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of the attributes of a has to be consistent with D in the sense that 
cr(^) = I with ^ G OId^ implies dom(^) = dom(C'.a<trs) and l{a) G 
for all a G dom(^). 

a is extended pointwise to lists of objects; thus a([])(a) = [] and ct(/i :: 
w)(a) = a{h){a) :: a{w){a). 

■ 7 describes the currently active method occurrences; namely, an event 
is active if it belongs to the domain of 7. The images of 7 consist of 
a (peutial) mapping of variable names to values, representing the valu- 
ation of the formal parameters of the method invocation, as well as the 
value returned by the method. The latter becomes defined only when 
the method has terminated; therefore the value can be _L. 7 also has to 
be consistent with D: if 7 (/i) = (i,v) for a given method occiurence 
/i G Evt^’^ then dom(f) = dom(M./pars) and i(p) E 

for allp G dom(^), and v G 

■ The transition relation satisfies the following property regarding the 

termination of method invocations: if an active method occurrence fi 
becomes inactive then is has a well-defined return value (i.e., not J_). 
Formally: if (cr,7) then /x G dom(7) \ dom(7') => ^ 

J_:7(^) = {£,v). Furthermore, we assume that Conf contains no ter- 
minated or deadlocked configurations; i.e., there is at least one outgoing 
transition from every element of Conf. (This property is imposed only 
for the sake of simplifying the definitions later on; it can be satisfied 
easily by adding a self-loop to every deadlocking configuration.) 

2.4. SEMANTICS OF BOTL 

We are now in a position to define the semantics of our logic. We assume 
the class declaration D to be fixed and given. Let © = LogVar — ^ Val, 
ranged over by 6 , be the set of maps that assign values to (some of) the logical 
variables. The semantics of expressions is given by the function |_J: Sexp — > 
(E X r X 0 ) Valjl. Let {a, 7) be a configuration of Md- 



I^L,7,0 


= 0 (z) 




Ie-aL,7,0 


= ^(a) 


where e G C ref and cr(|e]^ ,.^ g) = i 
or e G C.M ref and 7([eL,.Y,0) = v)^ 




= ^(o) 


where e G C ref list and cr([e]^ g) = i 
or e G C.M ref list and 7([el(^ 0) = (£, 


[e.owner]^_.^_g 




where 
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[e.return]^,^_g = v where7(Iel,,.^_g) = 

G dom(a) U dom(7)) 

[^(^1) • • • ) 6n)lo-,7,5 [^l(l^llcr,7,fi’ • • • > 

[with Z\ G ei from Z2 := do Z2 := 63]^,^ ^ 

= [for 2T1 G do Z2 := ^?^}aaMle2h,,,eh2} 

where [for zi G [] do 22 := ^ha,e 

[for ziehv.wdo 22 := 

= [for 21 € ri; do 22’:= 

Given the discussion of the operational model, the semantics should be self- 
explanatory, with the possible exception of the “with-from-do”-expression. 
This is evaluated by means of the “for-do” meta-expression, which successively 
re-computes the “do”-expression for every value of 21 out of the “for”-list.* 




Figure 2 An instance of the Hotel Class Diagram 



Example 2 . 2 . Consider the object diagram in Figure 2 , and suppose we want to 
compute z. rooms .guests in the configuration (a, 7) with variable interpretation 
0 :z 1-^ h. Skipping some details, we obtain 

Iz.rooms. guests}^ = a{lz.rooms}^.^g){guests) 

= cr(o-(Wo-,7,e)(^ooms))(5uesfs) 



*For those familiar with functional programming: with 21 € ei from 22 := 62 do 22 := 63 may 
alternatively be translated to /o/dl h-le 3 h,.r,e{h/zuv/z 2 )- 
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a {a (h) (rooms)) (guests) 
cr([ri,r2,rs])(guests) 
[[9i^92]d93^9A,95]A9e]] • 



As expected the result is a list of lists. 

The semantics of BOTL formulae is now straightforward. It is defined by a 
satisfaction relation between the model M d defined by the transition system, 
a reference configuration (a, 7), a valuation 9 and a formula (j). To define it, we 
need an auxiliary definition of paths through a transition model. Some notation 
first: if s e is an (infinite) sequence, we write 5[i] to denote the (i + l)-th 
element of 5; hence 5 = 5 [ 0 ] 5 [ 1 ] • • •. Given a model Md = ( Conf ^ a path 
is an infinite sequence of configurations r] G Conf ^ such that r][i] — > + 1] 

for all i > 0 . The set of paths starting in (cr, 7) G Conf is defined by 

Pmd(<^^ 7 ) = {v^ Conf^ I 77 [ 0 ] = (a, 7 ),V* ^ 0 :r?[z]-). r][i + 1]} . 

The semantics of temporal formulae is then given by a relation j= C (S x F x 
0 ) X Texp- 

Let {a, 7) be a configuration of Mo and let 6 E Q. 



a,'Y,e\=e 
a,j,9\= -1^ 
a,j,e \= 4>y xp 
a,^,6 \=\/z E T : (p 

a, 7 ,^|=E[W] 
cr,7,0\= A[(/>UV>] 



= tt 

~'{cr,7,0^ <f>) 

{a,j,9 1= (/>) V (a,j,9 |= V>) 
cr, 7 , 6{v/z} (f) for all v G Val'^ 

3r] E PTw^(a,7):r/[l],0 |= (p 
37 € PA<o(a, 7 ): 

3j> 0:r][j],9 \= xp A\/0<k<j:r][k],9 |= (p 
V7 € Ptwd(<t,7): 

3j> O: 7 y[i ],0 t= xp Ay0<k<j:r}[k],9 \= (p . 



3. TRANSLATING OCL TO BOTL 

In this section we will give a translation of OCL into BOTL and investigate 
differences as well as relations between them. First note that BOTL is not 
primarily intended to be the exact formal counterpart of OCL. In defining BOTL 
we were concerned with some issues derived mostly from our aim to do model 
checking of object-oriented programs. On the other hand, since OCL is not 
yet very “stable” in the sense that there are many proposals to improve it, see 
G-g- [10], our logic can be seen as one of the many “opinions” on how to give 
a sound foundation to OCL. At the same time, the translation provides us with 
a feeling above the expressiveness of BOTL. 
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3.1. OCL SYNTAX 

The set of OCL constraints and OCL expressions is given by the following 
grammar 

ix^)CocL "= context C invariant e I context C :: M(^ pre e post e 

(e E)Socl ■■= self | 2: | result | e@pre | e.a \ u>{e , . . . , e) 

I e.u}{e, ■ . . ,e) \ e-^u{e, . . . , e) | e->iterate(zi ;Z2 = e | e) 

As for BOTL we assume that OCL terms are type correct (with, however some 
differences in the possible types; see below). At the top level, a constraint x can 
either be an invariant or a pre/postcondition (see Section 1 ). The context of a 
constraint is a class C in case of an invariant or a method M E dom{C.meths) 
in case of pre/postconditions. The context can be referred to by the expression 
in the constraint. For instance, in an OCL navigation expression self. a, we 
describe a route starting from an object of the context class C. 

Many of the expressions e G Sqcl have their direct counterpart in BOTL. 

■ self refers to the context object of the class C. 

■ z represents either an attribute of the context object, or a formal parameter 
of the context method, or a logical variable. 

■ result refers to the value returned by the context method. @pre is a suffix 
that refers to the value of its operand at the time of the method invocation. 
These two operators can be used in postconditions only (see below). 

■ e.a and w(ei , . . . , e^) are the same as in BOTL. 

■ e.o;(ei, . . . , e„) represents an operator lo on basic types that is applied 
on e, ei, . . . , e„. If the expression e is a collection (i.e., a set, bag or list), 
we have the special case e-^Lo{ei, . Cn). 

■ ei->iterate(zi; Z2 = 62 | 63) has the same meaning as with zi G 
6i from Z2 := 62 do Z2 := es- The difference is only in the type that can 
be returned, namely sets and bags (see Section 3 . 2 ). 

Particular OCL features not included in the previous syntax are expressions of 
the kind M(e, . . . , e) and e.M (e, . . . , e) where M is a so-called query method', 
i.e. , M is a method which returns a value without side effects. Nevertheless, also 
constraints where query methods appear can be translated in terms of another 
OCL expression that does not contain them but that describes the function 
implemented by the query method^. Thus, as in other related works [ 11 , 19 ], 
we do not treat query methods explicitly. 



^Provided the function is not defined recursively. 
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3.2. TRANSLATION ISSUES 

Before proceeding with the formal translation of OCL into BOTL, let us give 
the intuition, in a rather informal way, of the solutions to the issues involved. 



Data types. One of the differences between BOTL and OCL is their type 
system: rather than arbitrary lists, OCL allows sets, bags and lists of primitive 
data values; i.e., nested lists are not included. There are two reasons why in 
BOTL we consider only arbitrary lists. On the one side, lists have sufficient 
expressive power to represent sets and bags; on the other side, by using only 
lists we avoid the problem of nondeterministic behavior in the BOTL expression 
with-do-from (this problem is present in OCL, see [19]). 

In order to have a more rigorous comparison, let us define OCL types. Then 
we will show how to encode them using BOTL types. We omit strings, reals and 
enumerations which are absent in BOTL but could be added without problems. 

p :;= nat | bool | C ref 
r(€ TypEocl) ■■■■= p\p list I p set I p bag 

p set are sets of elements of type p, while p bag are multisets whose elements 
have type p. The semantics of the sorts included in Type is unchanged, while 
for the new types we have: 

= 7^(Val^) 

Val^‘’®8 ^ Val^— )-N 



where V{-) represents the set of all finite subsets. The set of values in OCL is: 



Y Ah OCL = [J Val^. 

reTYPEocL 

Now let us discuss how we will translate OCL operations on sets and bags, 
say ei-^u){e 2 , . . . , e^). For OCL types p set and p bag, we define a function 
aset and abag on BOTL values. These functions abstract from the order of the 
elements in a list and return a set or a bag. Formally aset : Val — > Y Ah o cl 
is given by 



0!set(^) — ^ 



0 

{h}Uastt{w) 

V 



ifu = [] 
if V = h :: w 
otherwise. 



Using {] • D as notation for bags and l±l for their union, abag •’ Val — > Val ocL 
is given by 



Q^bag(^) = < 



u 

{|/l|} l±) abag(^) 



if ^; = [] 
ifv = h :: w 
otherwise. 
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For each operation ei^u>{e 2 , . . . , e„) on sets or bags, there exists a correspond- 
ing operation in BOTL, say u){ei,e 2 , ■ ■ ■ , Cn), such that the diagram in Figure 3 
commutes. This shows in which sense the translation of OCL into BOTL is 
faithful. 






a 



a 



Val" Val 

[<Sl 



Figure 3 Commutative diagram. 



Example 3.1. Consider the OCL expression ei->union(e 2 ). The intended se- 
mantics \union\ is the mathematical union on sets. In BOTL, there will be an 
appropriate operator with semantics \union\ ; Val^ x Va l'’' > Wa\7 

According to the commutative diagram, we have that Q'set([«”*o’'i(^i) ^ 2 )!) = 
[union] (aset(i'i), «set(u 2 ))- That is, the result on lists is equal, up to a bstrac- 
tion from sets, to the corresponding union on sets. The operator union can be 
defined for instance as union(^i,w^= concat{wi,W 2 ) where wi and W 2 are 
lists. 

Example 3.2. Consider now equality on sets in OCL: ei = 62 where ei and 
€2 have type set. The corresponding BOTL expression will have semantics 
1=1 : Val’’ X Val’’’ — > Val*’°°'. The operator = is defined as follow: 

={wi,W 2 ) = EqList{sort{del -duplicates {wi)), sort{del -duplicates {W 2 ))). 

Apart from del. duplicates, the same argument applies to bags. 

Invariants. The key issue for the translation of context C invariant e, con- 
cerns the identification of the states in which the invariant expression e has to 
hold. In particular we have to ensure that none of the methods in dom {C.meths) 
is active. In fact, during the execution of methods, there can be some interme- 
diate configurations in which e does not hold (see Example 3.3). 

Pre/postconditions. The translation of pre/postconditions is more involved. 
In particular, the OCL operator @pre has to be handled in a special way as it 
forces us to consider two different moments in time, viz. the start and end of 
a method invocation. We use the following strategy. Consider the constraint: 
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context C :: M{^ pre epre postepost- By definition, e@pre subexpressions 
occur a finite number of times, say n > 0, only in epost- We first enumerate 
all the occurrences of e@pre subexpressions in Cpost- We write e@ipre for 
I < i < n. Then when we translate epost» by means of the function 5 that 
we will define in the next subsection, we substitute terms e@ipre with new 
fresh logical variables U{ € r* for 1 < i < n. The value of the variable Uj 
is bound to the appropriate value in the translation of Cpre- We “add” to the 
translated precondition <5(epre) a binding term Ui = 6{e) for all U{ and e@ipre. 
Thus, the variables Uj are associated to the value of e in e@ipre at the beginning 
of the method execution, and therefore can be used instead of e@ipre in the 
postcondition. Note that the judgment u, € Xj can be inferred by the type of e 
in e@ipre. 



3.3. TRANSLATING OCL EXPRESSIONS TO BOTL 



We will now define a syntactic mapping of OCL into BOTL. First we will 
give a partial function 5 that translates OCL expressions. Then by means of 
5 we will address the issues involved in the translation of OCL constraints. 
The function 5 takes three parameters: o, m, p. Given a x € Cqcl^ the first 
parameter o represents a variable bound to an object of the context class C. In 
case of pre/postconditions, the value of parameter m is a method occurrence 
of the context method M and p is the list of its formal parameters. In case of 
invariants, m has an arbitrary value whereas p is the empty list. The translation 
function 5 : Sqcl — ^ (LogVar x LogVar x VName*) — > Sexp is given by 

•^o,m,p(s6lf) = O 



^o,m,p{^) — \ 



O.Z 



m.z 



z 



if o € C ref and ^ G dom(C'.atirs) 

if z ^p 

otherwise 



<5o,m, pC^esult) = m. return 

^o,m,p(6@iPI'6) = Ui 

z ( \ /y^®^(<^omp(e)-o) if eG (S' ref list and C'.aftr-s(a)=r list 

otherwise 

^o,m,p(^(®l) • • • ) ^n)) ^(<^o,m,p(®l)) • • • ) 

^o,m,p{^-^{^li • • • ) ®n)) ~ ^(^o,m,p(®)> ^o,m,pi^l)i • • • ) ^o,m,p{^n)) 
^o,m,pi^ ) Cn)) = ^(^o,m,p(®)) ^o,m,p(^l)> • • ■ > ^o,m,pi^n)) 

<^o,m,p(ei^iterate(zi;z2 = C2 | 63)) = 

with zi G ^o,m,p(ei) from 22 := ^o,m,p(e2) do 22 := <Jo,m,p(e 3 ) • 
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The translation of Sqcl is straightforward for almost every operator. 

■ A variable z is prefixed by the context object if it is one of its attributes; 
it is prefixed by m if it is among m’s formal parameters. 

■ As discussed in the previous section, in translating e@pre, we assume 
an enumeration of their occurrences, say e@ipre for 1 < i < n. Each 
numbered expression is then replaced by a fresh variable Uj. 

■ In case of attributes or navigation e.a we apply the definition recursively 
on the prefix. If both e and a are lists then the resulting BOTL expression 
has to be flattened since the result would produce a nested list that is not 
admitted by OCL. This is done explicitly with the operation flat. 

■ The expressions e— >w(ei , . . . , e^) and e.u{ei , . . . , e^) are translated us- 
ing the corresponding BOTL (n -f l)-ary operation ut. 

3.4. TRANSLATING OCL CONSTRAINTS TO BOTL 

In this section we will complete the translation of OCL into BOTL by defining 
a map A : Cqcl — s- Texp- 

Invariants. In case of an invariant, the translation has the typical prefix AG. 
The invariant must hold for all active objects of the class C when none of their 
methods is active. Let y G LogVar and dom{C.meths) = {Mi, . . . , M^}. 
We define: 

A (context C invariant e) = 

AG[Vz G act(C' ref) : Vmi G z.M\ ref : ... : Vm^ G z.M^ ref : 
(-iact(mi) A ... A -.act(mjk)) ^ <^ 2 ,j/,D(e)]. 

The reader is invited to check that the BOTL equivalent of OCL invariant (1) 
is indeed the expression (3) when the collection guests is a bag. 

Pre/postconditions. As discussed above, we augment the precondition with 
some extra information that is used to evaluate the postcondition. 

Consider the OCL constraint context C :: M{p) pre Cpre post Cpost- The 
extended translated precondition w.r.t. the object o and the method occurrence 
m, is given by 

-(gpre) A j\^ (ui = ^o,m,p(6)) 

eQipreecpost 

where Uj for 1 < i < n are fresh logical variables. 

Here the symbol G means “occurs syntactically in”. Thus, given a precondition 
Cpre we can build an extended precondition Cpf^’^ using a new variable Ui for 
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each subexpression e@ipre involved in the postcondition, which “freezes” the 
value of e while evaluating the precondition and can be used instead in the 
postcondition. Now we are ready to map OCL pre/postconditions to BOTL. 

A(context C :: M(^ pre Cpre post Cpost) = 

Vui € Ti, . . . , G : V 2 : € act((7 ref) : Vm G z.M ref : 

^ -act(m)) =» 

AX[act(m) ^ A[act(m)U(term(m) A <5z,^,p(epost))]] 
where term(m) = act(m) A EX[-iact(m)]. 

The expressions Cpf^’^ and Cpost are embedded in a kind of “template” scheme. 
Intuitively, a pre/postcondition holds if and only if for all invocations m of M 
executed by an object of the class C we have that: if the (extended) precondition 
holds at the moment of the method call, then the postcondition holds when the 
method execution terminates. This must be true for all active objects of C and 
all possible executions of the method M. In other words, a pre/postcondition 
is actually an invariant on method calls. 

Example 3.3. Suppose we want to translate pre/postcondition (2) in Section 1. 
Again, let us call the precondition Cpre and the postcondition Cpost- Consider 
two logical variables z and m. The former will be instantiated with an object of 
class Hotel and the latter with an occurrence of the method checkin. Applying 
S to 6pre yields: 

s(not guests— > includes {g)) = -iSz^rn,g{guests— ^includes (g)) 

= -'includes {z. guests, m.g) 

where includes is a BOTL operation that, given a list w and an element I, 
returns tt if and only if the element I belongs to w. The extended precondition 
becomes: 

= ~'includes{z. guests, m.g) f\ui = 5z,m,g{9'ii^sts) 

= -yincludes{z. guests ,m.g) Au\ = z. guests 

After some calculations, the translation of the postcondition yields: 

^z,m, 9 (epost)= 5z,m,g{guests^size) = 5z,m,g{guests@pre^size) + 1 
A 6z,m,g{guests-^includes{g)) 

= {size {z. guests) = size {ui) + l A includes{z. guests, m.g)). 
The translation of (2) now yields: 

Vui : V 2 ; G act(Hotel ref) : Vm G z. checkin ref : AG[(epr”’® A -iact(m)) 

=> AX[act(m) ^ A[act(m)U(term(m) A ^ 2 ,m,s(epost))]- 
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Figure 4 describes the configurations of the transition system during the exe- 
cution of the method checkin and indicates how the validity of the pre/postcon- 
dition changes. The second and the third column describe how the components 
a and 7 evolve w.r.t the configuration (first column). In configuration 1 object 
gi does not belong to the guests of h. The set of method calls is empty. In this 
state -yact{checkln) and the precondition epre are valid. In configuration 2, the 
method is active and, as a first step, gi is inserted among z guests. Thus, epre 
does not hold anymore. However, from this state Cpost becomes valid. In con- 
figuration 3, gi is assigned to room r and the method execution ends. Finally 
in configuration 4, checkin is not active anymore, and the postcondition Cpost 
still holds. Notice how in this example it becomes clear why the invariant (1) 
does not hold during the execution of checkin. 



2 



3 




-’act(c/iecfc/Ti) 

fiprs 



act(chccfc/n) 

€post 



Bci{checkln) 

-'epre 

Cpost 



-‘act(c/iccA:/7i) 

iBpaft 



Conf 7 



a Valid formulae 



Figure 4 Configurations during the execution of checkln(pi). 
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4. CONCLUDING REMARKS 

The temporal logic BOTL developed in this paper, facilitates the specification 
of static properties (similar to OCL) and dynamic properties (using CTL) of 
object-based systems. The syntax and semantics of the logic were formally 
defined, and a translation of OCL into BOTL has been presented, thus providing 
a formal semantics to a large subset of OCL. In the future we plan to extend our 
approach towards subtyping and inheritance, and to work towards an effective 
model checking approach for BOTL. The latter issue requires a treatment of the 
potentially infinite number of active objects and events (method invocations). 
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Abstract: There is currently considerable interest in the formal specification of 

distributed multimedia systems, with the majority of research in this area 
considering the use of timed formal languages for the specification of such 
systems. In contrast, however, there has been less research on the specification 
of stochastic behaviour, and yet this style of behaviour is predominant in this 
class of system. We therefore present stochastically enhanced timed automata, 
as a solution to the problem. The paper also introduces an associated tool suite 
that supports the editing, composition and simulation of such automata. 

Finally, a multimedia example is presented, illustrating the use of the enhanced 
automata and the associated tool suite. 



1. INTRODUCTION 

In our previous work, we have been interested in the development of 
methodologies and techniques for the specification and verification of 
distributed multimedia systems, with particular emphasis on object and 
component-based systems [Blair98a]. This has led us to develop an aspect- 
oriented style of specification that follows the principles of aspect-oriented 
programming [AOPOO][Murphy99]. Essentially, we decompose a system 
specification into four aspects: functional, non-functional, management and 
requirements. Motivations for this choice can be found in [Blair99c]. In the 
(aspect) programming world, once written, the aspects must be woven 
together using a set of identified join-points. There is a nice parallel here 
with aspects in a specification world: once written, our aspects are composed 
together (using standard parallel composition rules) and the join-points 




328 



become the set of actions (events) on which synchronisation occurs. Prior to 
this paper, our common model has been taken to be timed automata, along 
with their underlying timed labelled transition system semantics. Within this 
framework, we support a multi-paradigm approach, where (if appropriate) 
different aspects of a system may be specified in different formal languages. 
A detailed description of the semantics of translation and composition in this 
approach was presented in [Blair99a] and details of a tool suite developed to 
support our approach can be found in [Jones99a]. 

Using this approach, we have been able to capture the real-time 
information of object-based distributed multimedia systems and their 
associated quality of service (QoS) parameters such as latency, throughput 
and jitter. However, up to now, we have not been able to represent stochastic 
information. So, whilst we can specify that a communication takes n units of 
time (latency) and may vary by ±5 time units (jitter), we cannot allow for the 
possibility of, for example, extreme delays (due to congestion, or 
client/server down-time). This paper presents a stochastic extension to our 
approach, permitting the specification of the distribution of event timings 
(typically associated with some distributed communication, though not 
necessarily). Clearly, we would like to adopt a technique that will fit within 
our aspect-oriented and multi-paradigm framework and that can be 
supported by an extension to our tool suite. 



2. STOCHASTIC MODELLING TECHNIQUES 

2.1 Overview of techniques 

There exists a wealth of literature on stochastic process models such as 
Markov chains and generalised semi-Markov processes [Glymi89], graphical 
representations of such processes using stochastic Petri nets (including the 
generalised stochastic Petri nets of [Marsan95]) and more abstract notations 
such as queuing networks [Gross85]. Recently, much interest in stochastie 
process algebras has lead to the development of a number of formalisms 
such as EMPA [Bernardo96], GSMPA [Bravetti99], PEPA [Hillston96], 
SPADES [D’Argenio99] and TIPP [Hermanns96]. Our particular interest 
lies in techniques that fit our multi-paradigm framework and can be 
supported by extending our current tool suite. As mentioned above, our 
framework uses timed automata based on a timed labelled transition systems. 
The work of [D’Argenio99] (and [D’Argenio98]) is particularly interesting 
in that, in addition to describing the stochastic process algebra SPADES, it 
introduces a stochastic automata model based on probabilistic transition 
systems with general distributions. The process algebraic model has already 
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been analysed in the context of a simple multimedia system [Bryans99] and, 
as such, we are confident that it could be used within our framework and 
domain of distributed multimedia systems. However, in order to fit our 
framework, we need to adopt a new common model based on stochastic 
automata. Consequently, we focus further on this technique below. 

2.2 Focus on SPADES 



We are primarily interested in the stochastic automata of [D’Argenio99] 
in this paper (rather than the higher-level process algebra). Stochastic 
automata are finite state automata extended with clocks. Instead of these 
clocks being used to model deterministic timing, they are defined to take a 
random value set according to a given probability distribution. Once set, 
clocks count down (unlike timed automata where they count up). When the 
clocks reach zero, they enable certain transitions. Depending on required 
interactions with the environment, transitions need not fire immediately, but 
may wait until all clocks controlling an interaction reach zero. 

To illustrate the firing of transitions, consider the two stochastic automata 
in figure 1, both involved in an interaction on a transmit event. The timing of 
this event in the first automaton is governed by clock x sampled from a 
distribution Fx(t), whilst the timing of the event in the second automata is 
governed by clock y sampled from a distribution Fy(t). The setting (and 
resetting) of clocks is depicted by the inclusion of a clock name within a 
state, as in the initial state of each automata below. Since SPADES supports 
general distributions (not just exponential distributions as in many stochastic 
techniques), there is no restriction on what distributions are used. 




transmit, {x} 



transmit, {y} 



Figure 1. Stochastic Automata in SPADES 



When composed, both clocks are initialised (i.e. set to a value sampled 
from the associated distribution). The automaton containing the clock that 
reaches zero first must wait to synchronise with the other automaton (wait 
until the other clock reaches zero). This results in a situation where you can 
think of clocks as being allowed to go negative, with a transition being 
enabled when all involved clocks have values of zero (or below). 
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2.3 Stochastic versus timed automata 

The behaviour described in the stochastic automaton above is subtlely 
different from a traditional (deterministic) timed automata model, where 
clocks count up and a combination of guards, resets and invariants are used 
to control the timing of events (although we do not use the latter in figure 2 
below). In order to compare models, we present a similar example to above 
in timed automata. We assume the existence of two constants, cl and c2, 
used as lower bounds in the guards of our automata. 

“o"'’' y:-0"*O *'0^ 

Figure 2. Timed automata 

When composed, both clocks are explicitly initialised and the automata 
then idle in their respective initial states until one of the clocks reaches its 
desired bound (cl or c2). The first automaton to reach this point continues to 
idle until the other automaton is ready to participate in the event. 

Our two models differ if we assume that the automata provide a complete 
model of our system (i.e. no outside influences affect the timing of events). 
This is also referred to as a closed system. If this is the case for the stochastic 
automata model in figure 1, the transmit event will fire immediately the 
second clock reaches zero. This is known as a maximum progress condition. 
However, in the timed automata model depicted in figure 2, the clocks may 
continue to idle; there is no urgency for the transmit event to (ever) occur. 

Timed automata have traditionally addressed the issue of urgency by 
associating invariants with states. These determine the length of time that an 
automaton may remain in a given state before it must progress. The use of 
invariants has sparked off many debates, particularly with respect to the 
likelihood of time-locks arising in a composed system [Bowman99]. This 
itself has prompted the development of other timed automata models that 
include a notion of urgency but avoid invariants, such as timed automata 
with deadlines (TAD) [Bornot98]. However, these issues are aside from our 
purpose in this paper, so we continue our example using timed automata 
with invariants. 
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y:-0"*O 

[x<=max(cl,c2)] [y<=max(cl,c2)] ^ 

Figure 3. Timed automata with invariants 

In this system, once max(cl,c2) is reached, neither automaton may 
remain in the same state. Since both have an enabled transition, t\\Q transmit 
event, this must fire immediately (before time can progress further). It should 
be obvious that the solution that we have presented in figure 3 is not ideal 
since the invariant of one automaton relies on “global” information, namely 
the lower bound of the other automaton’s guard. However, using only 
“local” information increases the potential for time- locks. 

To conclude this section, the stochastic automata of SPADES provide an 
elegant low-level representation of stochastic behaviour, where the timing of 
events can be governed by any distribution. This approach fits in well with 
our desire to find a suitable low-level common model for our aspect-oriented 
and multi-paradigm approach. However, the downward counting of clocks 
differs from our existing model and, as such, would require substantial re- 
definition of our (multi-paradigm) framework and re-implementation of our 
tool suite. Furthermore, we make heavy use of untimed variables in our work 
(e.g. counters, variables representing desired rates of transmission, permitted 
error rates, rates of throughput, etc). These are not defined for SPADES, 
although this should not be a difficult extension (at least at the automata 
level). Consequently, we define our own timed automata extension, inspired 
by the constants used in figures 2 and 3. 




3. EXTENDING TIMED AUTOMATA 

The timed automata clocks in figures 2 and 3 counted up to deterministic 
values represented by constants. For our distributed multimedia examples, 
we require a model whereby these constants can be sampled from an 
appropriate distribution. This is straightforward from a syntactic perspective, 
but requires more care with respect to the semantic relationship between the 
clocks and stochastic variables, and also the semantics of re-sampling. We 
must also move from our underlying timed transition system semantics to 
(timed) probabilistic transition system semantics. We explain the 
relationship between different semantic models below. 
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3.1 Underlying semantic models 

Labelled transition systems (LTS). We define a labelled transition 
system over Act, the set of (atomic) actions, to have the following form: 

LTS = <S, So, >) 

where S is a (non-empty) finite set of states. 

So G S is the initial state, and 
> c SxActxS is a transition relation. 

Intuitively, we now have a model with actions, states and transitions 
(labelled with actions) between states. As in LOTOS, we permit actions to 
have associated data (currently only integers in our tool suite) and denote 
output by “alvalue” and input by “a?var:var_sort”. The rules governing the 
synchonisation of events carrying data follow those of LOTOS ([IS089]). 

Timed labelled transition systems (TLTS). To extend labelled 
transition systems with time, we follow the approach of [Larseii95] and 
permit two sorts of actions: atomic actions (Act) and delay actions (A) whose 
elements are denoted by s(d) g A (for d g 3^). We denote the set of labels L 
as Act u A. Our transition relation from the LTS definition above must now 
also permit delay actions, and must satisfy the usual time determinism and 
time additivity rules [Larsen95]. 

We now have a timed semantic model where transitions are labelled by 
an action or a delay. In the first case, the set of action- label led transitions is: 

{s — s’ I aGAct and s, s’gS} 

In the second case, the set of delay-labelled transitions (for c(d) g A) is: 

{s — s’ I d G 3^ and s, s’gS} 

Unfortunately, at this low semantic level, the model yields an infinite 
structure. For example, an action occurring at a time less than 3 would (in a 
continuous domain) be represented by an infinite number of delay transitions 
each labelled with a time t (0<t<3), and each followed by the action-labelled 
transition. This infinite structure is clearly unmanageable as a modelling 
language, hence the development of higher-level models such as automata. 

Probabilistic transition systems (PTS). We can further extend 
transition systems to include probabilistic information. Suppose we have a 
transition occurring at time f where f is sampled from a distribution F, 
s — >s ’. Again, there are an infinite number of possible (delay) transitions, 
this time with the probability of each determined by the distribution F. 
Clearly, the sum of probabilities of all possible transitions should equal one. 

Probabilistic transition systems can be formally defined. However, their 
definition is mathematically complex and we believe that the above intuitive 




Stochastically Enhanced Timed Automata 



333 



definition is sufficient for this paper. We thus move on to define our timed 
automata model, and refer those wishing to see a complete formal definition 
of probabilistic transition systems to [D’Argenio98]. 

3.2 Timed automata 

Notation. The purpose of our timed automata model is to provide a 
higher-level, more manageable model than that provided by TLTS. We start 
with the timed automata of UPPAAL [Larsen95], but extend the model to 
permit data-carrying events as described above. Timed automata are finite 
state automata extended with clocks and variables; let C be a finite set of 
real-valued clocks and V be a finite set of real-valued variables. The subset 
D e V will be used to represent the set of data variables used to attach data 
to events (we currently distinguish between D and V since we restrict data to 
integers in our tool suite). We will let Var = C u V. 

Our timed automata model also permits gwartA (conditions on clocks or 
variables) on transitions and invariants on states (that must remain true 
whilst in that state). Let the set of constraints (guards) over Var be 
represented by G(Var). Note that the values of clocks and variables can be 
compared with constants and/or reset on transitions. 

Timed automata. We now define a timed automaton formally as: 

TA = ( S, So, >, I ) 

where S is a finite set of states, So e S is the initial state, > is a 

transition relation, and I : S->G(Var) is an invariant assignment function. 

Our transitions are more complex than for the timed transition systems 
above since they can now incorporate guards and resets. The format of a 
transition is thus the tuple: 

<1, g, a, r,r> 

where 1, V are nodes (locations) and a g L (as above), 

and g is a constraint (guard) s.t. g ::= x ~ c, and 

1(1) is an invariant (on location 1) s.t. 1(1) ::= [ x ~ c ], where 

~::=<| = |>|<|>,XG Var and c is a constant, 
r is a reset (or reassignment) function. 

The semantics of timed automata can now be defined in terms of timed 
transition systems. Each state in an automaton must now consist of the tuple: 

s = (1, Uc, Uv) 

where 

1 is a node (or location) 

Uc is a clock variable assignment function s.t.for clocks XeC, Uc:X->3 
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Uv is a variable assignment function s.t. for variables Y c V, Uv : Y 3 

and for data variables Z c D, Uv : Z -> 9 

The initial state is So = (lo, Uco, Uvo), where lo is the initial node, Uco 
initialises all clock variables [C aO] and Uyo initialises all variables [V a 0]. 

Intuitively, we now have a model containing a set of states where, at each 
state, we can query the value of clock variables (respectively variables) 
through the clock variable (respectively variable) assignment function. 

Finally, the semantics of the transition relation can be defined as follows: 

(1, Uc, Uv) > (!’, Uc’, Uv’) if g is satisfied by Ucand Uv , 

Uc’ = [r a r’]Uc and Uv’ == [r a r’]Uv, 

i.e. All guards must be satisfied, and those variables being reset are reset 
whilst the rest remain unchanged. 

(1, Uc, Uv) — -- > (f, Uc’, Uv’) if (1 = 1’), Uc’ = Uc+d and Uv’ = Uv, and 

I(l’) is satisfied by Uc’ and 14 ’. 

i.e. Time can pass whilst in a given state, providing the invariant still 
remains true after the passage of time. 

3.3 Stochastically enhanced timed automata 

In order to allow variables to assume stochastically sampled values, we 
define the set F of distribution functions and Fj g F. We use f ◄ Fj to denote 
that variable f is sampled from distribution F,. Such variables are denoted 
sampling variables, the set of which is SVare Var (all f g SVar). We now 
require an extended tuple to represent the semantics of an automaton’s state: 

s = (1, Uc, Uv, f) 

where f is a distribution sampling function s.t. for sampling variables SV 
cSVar,f : SV-^3. 

The initial state is as before, except that it now contains fnit- This ensures 
that all sampling variables referred to in the initial state are initialised to 
samples from their associated distributions (Vf g sv(Io), f < Fj). The 
current value of a sampling variable can be referenced either on guards or 
state invariants (similar to our use of constants in figures 2 and 3), such that: 
g has the form x ~ f | f ~ c, and 
1(1) has the form [ x ~ f ] | [f ~ c ]where 

fj is sampled from distribution Fj (denoted f ◄ Fj ). 

We also need to make reference to the set of all guards on outgoing 
transitions of location 1 (denoted GLi). We define the function g(l) over the 
domain G(Var) to return the set GL). We also define the function sv(l) over 
SVar to return a set of all sampling variables appearing in invariants or 




Stochastically Enhanced Timed Automata 



335 



outgoing transitions of 1 (SLi). We now require (in addition to the semantics 
for the transition relation for timed automata above): 

(1, Uc, Uv, f) > (r, Uc’, Uv’, f ) if for all f e sv(l’), f ◄ Fj 

i.e. All sampling variables referred to in invariants or outgoing transitions 
of the new location are re-sampled on entry into the new state. An example 
illustrating this is presented in figure 4. 

(l,Uc,Uv,f)-^^(l’,Ue’,Uv’,f)if f=f 

i.e. Values of sampling variables are unchanged by the passage of time. 
Finally, composition of our extended timed automata is governed by 
parallel composition rules, details of which are included in Appendix A. We 
now have a timed automata model with clocks that can count upwards 
towards values sampled from stochastic distributions. As can be seen from 
above, this requires minimal changes to the timed automata model. By 
taking this approach, we have also retained our standard (non-clock) 
variables and our data variables that we use to model data-carrying events. 



4. TOOL SUPPORT: LUSCETA 

LUSCETA is a tool suite that we have developed at Lancaster to provide 
support for the analysis of our stochastically enhanced timed automata 
(Lancaster University tool suite for Simulating, Composing and Editing 
Timed Automata). A first version of this tool suite offered support for the 
composition of different aspects written in different paradigms, and their 
subsequent simulation or model checking, but did not offer any support for 
modelling stochastic behaviour [Blair99b]. In addition, the tool suite 
supported the generation of timed automata from temporal logic and enabled 
interoperability with existing tools such as Eucalyptus [Garavel96] and 
UPPAAL [Larsen95]. For reasons of evolution, a large proportion of our 
original tool suite has now been rewritten using component technology, i.e. 
Java Beans [Jones99a]. Importantly, the tool suite has recently been 
extended further to support stochastically enhanced timed automata, as 
described by the semantics above. The use of component technologies in this 
area is noteworthy given the monolithic and closed nature of many existing 
formal tools. It is hoped that, by adopting this approach, LUSCETA can 
evolve rapidly to meet new requirements and that we can also promote the 
re-use of key parts of tool suites such as model checking algorithms. 

The editor in LUSCETA allows us to enter stochastic information 
relating to our automaton in the form of a header. Typically, we define a list 
of the required distribution functions (e.g. Uniform, Normal, Binomial, 
Poisson) with their appropriate parameters (e.g. range, mean, variance). We 
then associate sampling variables with these distributions. For example, let F 
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be a Normal distribution, F = N(10, 6.5) and f be an associated sampling 
variable, f F. Note that this corresponds to the sampling process referred 
to as f ^ F above. We can now use these directly in the guards and/ or 
invariants of our automaton (respectively, f ~ c and [f ~ c]) or, assuming we 
define t as a (clock) variable, we can compare the variable’s value with the 
sampled value (respectively, t ~ f and [t ~ f]). To illustrate this, consider the 
following simple automaton that makes use of a sampling variable f taken 
from the normal distribution F, as defined above. 

I Header Information: 

F=N( 10,6.5), f:=F 




Figure 4. Simple automata to demonstrate stochastically generated values 

Using our tool suite we can now simulate this automaton, sampling new 
values for f every time we enter the second state (according to our 
semantics). As can be seen, “good” actions occur when the sampled value is 
between 5 and 15 (which, for the stated mean and variance, corresponds to a 
95% confidence interval) and “bad” actions at other values. Table 1 shows 
the results of the count variable after varying numbers of simulation steps. 
As expected, the error count roughly corresponds to 5% of the steps. 



Table 1. Simulation results from the above automaton 



Number of steps 


Error count 


Time taken (seconds) 


10 


1 


1 


50 


2 


2 


100 


6 


4 


500 


21 


18 


1000 


48 


35 



Two further tool components are a graphical component that produces a 
graphical representation of the simulation steps (only appropriate for a 
small-medium number of steps) and a distribution component that produces 
a visualisation of the sampled values and how they fit the sampling 
distribution. All components are described in detail in [Jones99a]. We now 
consider the application of our automata and tool suite to a larger example. 





5 . 
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EXAMPLE: SYNCHRONISATION PROTOCOL 



5.1 Overview 

Many different algorithms have been proposed in the literature to handle 
the synchronisation of multiple media streams under varying assumptions/ 
conditions. For example, [Blakowski96] and other papers in the same journal 
cover a variety of different techniques. The algorithm that we will use in this 
example has been published recently in [Biersack99], In their paper, they 
present a synchronisation protocol for stored media by “stepwise 
refinement”. This means that a separate model is used to represent three 
incremental stages of the protocol design, as will be described below. The 
protocol assumes that the media units (mu) are distributed in a round robin 
fashion across distributed servers (see figure 5). 




Figure 5. Two distributed servers showing stream connections to a client 



5.2 The three models in detail 

The initial model of [Biersack99] addresses the problem of start-up 
synchronisation under the assumptions of constant delay and zero Jitter. The 
main problem addressed by this model is compensating for potentially 
different latency values for each server-client connection due to the 
distributed nature of the servers. Traditionally, delaying media units at the 
client by buffering data compensates for this. However, with large 
differences in latency this implies large buffers are required. Note that since 
the protocol is intended for stored (c.f. live) data makes this possible. 

This model is split into two phases: an evaluation phase and a 
synchronisation phase. The role of the evaluation phase is to obtain the 
earliest possible play-out time for the first media unit and, correspondingly, 
the required start time for each server. Also calculated is the required buffer 
space at the client. The synchronisation phase involves the sending of a 
message from the client to each server after which each server starts sending 
its data at the specified time. Earlier work has considered the modelling of 
these phases using an underlying model of timed automata [Blair99d]. 
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The second model relaxes the restriction on jitter by permitting bounded 
end-system jitter and network jitter (termed the maximum jitter strategy). 
The effect of jitter is that the temporal relationship within (and between) 
media stream(s) is destroyed, even though the media units may have been 
sent in a timely manner. Consequently, to smooth out the effects of jitter, 
buffering at the sink must occur. In order to illustrate our stochastically 
enhanced automata, we make a slight amendment to the maximum jitter 
strategy. Instead of having hard upper and lower bounds, we allow the jitter 
to be sampled from a Normal distribution. In a similar way to the example 
presented above, we select the parameters of the distribution such that we are 
95% confident that the jitter is within our allowable bounds. 

The evaluation phase is the same as for the first model, but the 
synchronisation phase requires a further property to be satisfied before play- 
out of a stream of media units (see [Biersack99]). The last sub-stream (one 
per server) to satisfy this property determines the play-out deadline for the 
stream. Different jitter bounds per sub-stream complicate the situation (by 
giving different play-out deadlines and buffer requirements). We determine 
the necessary buffer requirements from the sub-stream with the largest jitter 
bound. Due to jitter, these will clearly be higher than for the first model. 

The third model is more general still and can cope with alterations in the 
average latency, clock drifts and server drop-outs. In our example, we 
address the first two models, but not the third. 

5.3 Specification of the example 

Using timed automata to model the client and server. For the purposes 
of this paper, we choose to focus on the synchronisation phase. Note that 
automata for the evaluation phase can be found in [Jones99b]. Since we have 
chosen to relax the bounded jitter assumption, we add a transition to detect 
when the maximum jitter strategy fails (i.e. the jitter bounds are exceeded). 
If this occurs, we allow the play-out to continue as follows: if a media unit 
has failed to arrive by its play-out deadline, we increment an error counter 
and wait for the length of time it takes to play one media unit before trying 
again. Note that we should also check if the maximum buffer size has been 
exceeded, although this has not yet been included in the current version. 

Figure B.l (in Appendix B) shows the timed automaton representing the 
second phase of the client. After initializing some constants and variables, 
we send out play requests. We then wait until we have at least one media 
unit from each server and, once the play-out deadline has been reached, we 
start playing media units. We continue to receive media units from each 
server and play them on schedule (or generate an error) until all our media 
units have been played. On finishing, we analyse the number of errors in 
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order to decide whether our play-out was successful or not. If there have 
been errors, we can analyse the log to check that these have arisen from jitter 
outside the acceptable bounds (see following section). 

The server is much simpler in design, (figure B.2, Appendix B) receiving 
play requests and sending each media unit, in turn, at the required time. This 
enables the client to piece together each media unit with its complementary 
parts, ready for play-out. In our example, we assume each server contains 10 
media units (represented by variable N in the server automaton). 

Using stochastically enhanced automata to model the medium. The 

transition between the server and client (through a medium) is now quite 
complicated. The automaton in figure 6 models transmissions from one 
server and allows up to 4 media units to be in transit from any one server at a 
time. The automaton is duplicated for transmissions from the second server. 

After the play request has been sent, our transition automaton 
accumulates media units (by synchronising on the server’s snd mul event 
and the transition automaton’s addjnul event). The array-like notation 
AA[1,2,3,4] and multiple arrows have been used to simplify the 
presentation; they correspond to the 4 media units allowed to be in transit at 
a given time. The first media unit is used to decide when play-out may 
begin. To determine the transmission delay, we sample jitter from a Normal 
distribution, using different parameters for each server’s sub- stream. In the 
transition automaton above, samplel is used to denote the sampling variable 
from the distribution associated with server I’s sub-stream. This information 
is specified as a header to our automaton, e.g. F1=N(6, 0.26), samplel :=F1. 
When the sampled value is added to the client’s local time (variable//) we 
obtain the time at which the client receives each media unit. This involves 
synchronisation between the transition automaton’s event and the 

client’s in mul event. The media unit is now removed from the transition 
automaton’s buffer and buffered at the client until the play-out deadline. 
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6. ANALYSIS 

We believe that our stochastically enhanced timed automata provide the 
extra expressive power required for our domain and also fit elegantly into 
our existing framework. Furthermore, the formal semantics offer a precise 
description of the model for implementation purposes (and have shown up 
several flaws in our original design). We now focus on the use of this tool 
suite to analyse the behaviour of the synchronisation protocol. 

Firstly, it is important to point out that the bounded jitter algorithm 
presented in [Biersack99] is, by design and mathematical analysis, correct 
with respect to synchronised play-out and buffering requirements under the 
assumption of bounded jitter. Thus, it has not been our aim to find errors in 
this algorithm. Instead, the approach we have taken is to relax the bounded 
jitter assumption and sample the transmission delays from a Normal 
distribution such that 95% of the samples should lie within the required 
bounds. This permits us to demonstrate our stochastic enhancements to 
automata and to evaluate our tool suite. 

Having specified all automata required for this example, our first step is 
to compose them together using the standard parallel composition rules 
presented in Appendix A. Each transition automaton is composed with the 
corresponding server and then added to the client in turn. We then add the 
initial evaluation phase to give us the overall composition of the system. 
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Each stage of the composition takes of the order of 1 second or less to 
complete and our final automaton contains 348 transitions. 

In our analysis, we have simulated our system repeatedly (100 times) and 
collated results. Note that, for a single run, we have 10 media units per 
server and 2 servers, hence 20 media units in total. With an expected 5% of 
these giving errors, we would statistically expect 1 error per run. Of course, 
in practice our sampled values may give us a different number of errors. 
Consequently, for each simulation run, we were particularly interested in the 
number of errors in that run and the cause of the error (i.e. checking the log 
to ensure that the error arose due to a sampled time outside the required 
bounds). After running the simulation 100 times, we noted errors in 78 of the 
runs, with a total of 93 errors. Each run typically consists of approximately 
100 steps and the log for each one of these takes approximately 5 seconds to 
generate. An annotated screen-dump of a portion of the log from one of the 
simulation runs resulting in an error is shown in figure 7. 

At each step of the simulation, the log provides us with a list of possible 
transitions. Some of these may be unavailable due to guards not being 
satisfied. All available actions are listed on the main interface. At this point 
in the log, transition 14 is the only one listed as available, hence we must 
take this transition. The last line shows the current values of all our variables 
and, importantly, shows our error count equal to one. This indicates that in 
the simulation, one media unit failed to arrive by its play-out deadline. 




I 14 K JioM Uw' Diily' one avnilubltl 

(MB [f is listed all other transitions fkim the stoto) 

'ana inimii ■ ftiHCiM *1 ; S4 

^r»5 9.S4, Inmij2: buffBr2 = tKJttar2'Hi ; 94 
ans 1 D:fi4; iti=r,bnirQM=0, pia^taifof; F counter count* i ^in:=0, S4 
ms 1 1 :S4: H1^T,bu(lbr2^0, plursirw; FcaunL=f tDunl^-1 S* 

jans 1 2:34, btrfTbM ^O.buffBr2^Q.tt1 =r; pla^; butTBrl :=butlbr1 •t,buttor2:=bijfl^r2-1^^unt=NcDiJ0l*1,tt1 84 
Ians 13 54; buffiarT=a,bLrtrarJ==D.NcQLjn.t=lM,Fcount=0, onijplay; >:TRUE 
[tansT* bufferl ^0.biJtrei^==0.Ntoun^N.Fcciur>t>S. cfideiTpr. W aLSE 
km : tt1=a.Qj 

Enables 

: 



Wo do transition 14 



cqiiiil lu ihc ntimber in ihi: sLrcani 



Our error count is > U 



Figure 7. A simulation run resulting in 1 error 

To see where this error occurred, we look further back in the log (figure 
8). We find an available transition (numbered 11) about to be taken. Note 
that the previous transition (10) \s> unavailable since the guard bufferl==0 is 
false. Also observe that the client’s play-out deadline (2 time units) has been 
reached by variable Itl, and that buffer2 is still empty. Hence, although a 
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media unit from server 1 has already arrived {buffer] -1), we cannot play-out 
since the media unit from server 2 has not yet arrived. We must thus delay 
the play-out further, report a playerror event and increment our error count. 
No other errors were generated on this run since our final error count was 1 . 



An error transition is ready to tire 
Trans 10:54; It1==r,buffer1==0; playerror; Fcount:=Fcount-«-1.lt1 :=0; S4 
iTrans 11:54; It1==r,buffer2=0; playerror; Fcount=Fcount-«-1,lt1 :=0; 54 | 

Trans 12:54; butrer1>0,butfer2>0,lt1==r; playmu; bufferl :=buffer1-1,bL 
Trans 13:54; bufferl ==0,buffer2==0,Ncount==N,Fcount==0; endplay;? 

Trans 14:54; bufferl ==0,buffer2==0,Ncount==N,Fcount>0; enderror;ilf 
Clocks :lt=1 5.0; It1=2.0; 

Variables : 51=5.0; 52=2.0; 51 c=27.0; 52c=24.0; dv1=1 1 .0; dv2=1 1 .0; ... Fcount=0.0| 
looing 11*" 






Do the error transition 






bufferl =1.0; buffer2=0.o| 



butter! is ready but buffer2 is not 



Figure 8. Part of the log showing a playerror transition 

One point that was not detected in our analysis, however, was that of 
buffer overflow. Because our buffering requirements were based on the 
maximum jitter assumption, relaxing this assumption leads to new (larger) 
buffer requirements; if these requirements are not met, the possibility of 
buffer overflow exists. Our analysis was based only on a sample of 20 media 
units which, on simulation, was not sufficient to generate a buffer overflow. 
We clearly need to greatly increase the number of media units and insert a 
break-point capability into our tool (allow it to run continually until a certain 
condition is met). Alternatively, we could look at more complex simulation 
strategies based on, e.g., visiting each state (or transition) at least once. 

To summarise, our relaxation of the maximum jitter bounds has allowed 
us to demonstrate our stochastic enhancement to timed automata. In the 
analysis, we have benefited greatly from the use of our tool suite, although 
we have identified certain desirable extensions. We should also point out 
that we have focused on real-time analysis and simulation. The former can 
be extended to probabilistic analysis by incorporating semantics based on 
probabilistic transition systems, e.g. to allow questions such as what is the 
probability of reaching a given state. The latter can be extended by including 
other forms of verification, such as (stochastic) model checking (see below). 



7. CONCLUSIONS AND FUTURE WORK 

Previously, we have developed an aspect-oriented and multi-paradigm 
framework for the specification of distributed multimedia systems. This 
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proved to be successful in a number of case studies, but clearly did not 
support formal reasoning about the stochastic behaviour of such systems. 
This is a significant problem, given the predominance of such behaviours in 
this field. We have therefore extended our previous work, inspired by 
research into stochastic automata, particularly SPADES. By developing 
stochastically enhanced timed automata, we have retained compatibility with 
our framework. We have also described a component-based tool suite, 
LUSCETA, to support our methodology. LUSCETA currently enables the 
editing, composition and subsequent simulation of stochastically enhanced 
timed automata. Being component-based, the architecture is naturally 
extensible and further developments are planned (see below). With a small 
amount of additional implementation, the new model will enable us to 
support our more general multi-paradigm specification architecture, with the 
stochastically enhanced timed automata providing a common underlying 
model. The paper has also presented a multimedia example illustrating the 
use of the enhanced automata model and associated tool suite. 

One limitation with the tool suite is that composition is performed before 
simulating the system, thus leading to the inevitable state-space explosion 
problem. On-the-fly techniques are currently being considered to improve 
the ability of the tool suite to handle large systems. A further limitation is 
that we have only addressed the simulation of our extended automata. 
Ongoing work is addressing other forms of verification such as stochastic 
model-checking (incorporating probabilistic transition systems). This work 
is being carried out in collaboration with the University of Kent at 
Canterbury (see acknowledgements). In addition, our collaborators have 
considered the mapping of stochastic automata to timed automata (actually 
timed automata with deadlines), to enable existing real-time model checking 
tools and techniques to be exploited [Bryans99]. We plan to extend our tool 
suite with such techniques as details are finalised. We also plan to 
investigate the timed automata with deadlines model as a means of 
eliminating time-locks in a composed system. 
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APPENDIX A. COMPOSITION 

Composition of our stochastically enhanced timed automata follow the 
parallel composition rules defined below. SA is the set of actions on which 
the execution of each automaton should synchronise, and sf(ai,a2) is the 
synchronisation function governing the synchronisation of events ai and a2 
(see [IS089]). Let si=(li,Ud,Uvi,fsi)e TA| and S2=(l2,Uc2,Uv2,fs2)G TA2, where 
TAi=(S|,Soi,->,I) and TA 2 =(S 2 ,So 2 ,^,I) are stochastically enhanced timed 
automata. Let L = Actu A and aeL. Composition rules for TA| and TA2 are; 
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T able 2. Composition rules 



g>a,r 



SA 



g.a,r 



■^^rilsA ^2 



g,a,r 



->S 2 ',a SA 



g,a,r 



M IISA ^2 



->s 



1 IISA ""2 



Sj — — >Sj',S 2 — — > 82 ', a 6 SA where sf(al,a2) = a, 



g.a,r 



IISA ^2 



■^^riisA ^2' 



g = gl A g 2 and r = rl u r 2 









■^®l'llsA ^ 2 ' 



The resulting composition can be defined as: 

Comp = < S, So, >, I ) 

where S is a finite set of states s.t. S] S 2 e S o S| e Si and S 2 e S 2 , 

So e S is the initial state s.t. So = Soi ||sa So 2 > 

> is the transition relation governed by rules 1-4 above, 

I(S, llsA S 2 ) = I(Si) A I(S2) 

With respect to the resampling of variables, recall that the function sv(l) 
returned all sampling variables contained in the outgoing guards or invariant 
of location 1. Consequently, for rule 1: Vf e sv(l]), fj ◄ Fj , for rule 2: Vfj e 
sv(l 2 ), fj ◄ Fi , for rule 3: Vf € sv(l|) u sv(l 2 ), f ◄ Fi , and finally for rule 4: 
f = f, i.e. no sampling variables are re-sampled. 
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APPENDIX B. AUTOMATA FROM SECTION 5 
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Figure B.L Client automaton for the second phase 




Figure B.2. Server automaton for the second phase 
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Abstract We describe an approach to formally specify object-based software com- 
ponents, in order to be able to automatically check their behavior at 
run-time. The specification is a regular expression built from the propo- 
sitions about the states (or pairs of states) of a component. Checking is 
done by a specification-generated wrapper, which produces a fail-stop 
component from a component which fails in an arbitrary way. The 
wrapper-generator is implemented for a subset of Java classes. We ar- 
gue that specification-based error-detection is particularly suitable for 
the components of open, object-based distributed systems. 

Keywords: Formal specifications, run-time checking, component wrapping, appli- 
cation generators, correctness by construction, fault-tolerance. 

1. INTRODUCTION 

Open object-based distributed systems challenge the traditional ways 
of applying formal methods via specification and proof. One of the prob- 
lems is the large number of the components involved, which are partly 
decided at compile-time (static invocation) and partly at run-time (dy- 
namic invocation). Another problem is having to rely on the vendor’s 
claims about correctness of individual components, without being able 
(lacking the implementation details) to verify such claims ourselves. Yet 
another is expressing component specifications in an interface defini- 
tion language, which describe how to communicate with a component 
(syntactic level), but not the expected results of such communication 
(semantics). Such problems make static verification difficult, at best. 



* Institute of Mathematics, University of Gdansk, Poland. 





352 



On the other hand, the structuring of the whole system in terms of the 
independent, distributed components, is particularly suitable for fault- 
tolerance [7]. The goal is to make sure that the failures of individual 
components (violation of their specifications) will not cause the whole 
system to fail (violation of the system’s specification). The latter spec- 
ifications can be used at design-time to prove if the system is indeed 
fault-tolerant. The former can be used at run-time to detect if a com- 
ponent has failed. This paper describes an approach to formally specify 
software components in order to make such error-detection possible. 

Defining such specifications is not without problems. Specifications 
may contain infinite constructs like quantifiers (for all values of a type), 
liveness properties (for all states in a sequence) or modal properties of 
branching time (for all transitions from a state) . Such constructs are gen- 
erally non-executable - we cannot execute them directly on the machine, 
and non-checkable - we cannot check effectively at run-time that they 
indeed hold. On the other hand, specifications based on propositional 
logic are not enough expressive in practice. Finally, checking specifi- 
cations which use equality of states is not possible when the state can 
be only accessed via defined operations; the best we can do is checking 
bisimilarity [9]. Such problems require a different kind of specification 
for effective run-time checking than those for static verification. 

In this paper we propose a specification approach for software com- 
ponents which is suitable for their checking at run-time. The technical 
approach is as follows: (1) Specifications are formally-based. They are 
defined as logic-based regular expressions built from the propositions 
about the states (or pairs of states) of a component, via its observer 
operations. (2) Specifications are checkable at run-time, based on the 
recorded history of the component’s execution, a sequence of observer 
values about individual states and the operations which caused state- 
changes. (3) Checking is carried out by a wrapper which is generated 
from the component and its specification. The wrapper takes over all 
communication between the component and its environment. It remains 
transparent to the clients except being able to detect (carrying out run- 
time checking after every state-change) and announce (via the additional 
boolean observer error) the occurrence of an error. (4) The required ef- 
fect of run-time checking is described formally as the fail-stop property. 
The wrapper- generator is to transform a given component, which may 
fail in an arbitrary way, into a component which only fails by refusing 
to operate, also announces this fact. The formal model in RAISE [11] 
with justification of the correctness of the wrapper-generator (that every 
wrapped component is fail-stop), is the subject of a companion paper. 
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wmp 




faiLstop 

7 

A error 
A error 



Figure 1 Fault-free versus fail-stop software components 



Figure 1 provides an illustration. It describes the intended result of 
the wrapper generator for specifications given as state invariants. The 
component comp may or may not satisfy the invariant spec but its trans- 
formed version wrap{comp, spec) satisfies the ‘fail-stop’ version of spec: 
spec holds if and only if error is false. Importantly, this property is not 
verified for each component and its specification but proved about the 
wrapper-generator, then applied to all components and specifications. 

The rest of this paper is as follows. Section 2 explains and illus- 
trates the concept of a ‘component’. Section 3 discusses and compares 
‘fault-free’ and ‘fail-stop’ behaviors of components. Section 4 shows how 
to ensure fail-stop behavior by patter-matching. Section 5 presents an 
example, a line editor. Section 6 describes how pattern-matching can 
become part of an automatically generated wrapper, also describes a 
prototype implementation for components written in Java. Section 6 
provides some conclusions and directions for our future work. 

2. COMPONENTS 

We treat a component as a entity with its own state and the opera- 
tions defined on it. The state is internal - the operations are the only 
means to give access to it, persistent - it maintains its value between 
operation invocations, and the operations are atomic - to execute them 
concurrently is the same as executing them in an arbitrary order. 

We represent the state-space of a component as an abstract type State 
and its operations by the functions on this type. Depending on the 
type of access we divide the operations into ‘readers’ which return a 
value without modifying the state and ‘writers’ which change the current 
state without returning any value. Readers are further divided into 
‘constants’ which return some value independent from the current state 
and ‘observers’ which return a value based on the current state. Writers 
are divided into ‘generators’ which return a new state, independent from 
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the current one, and ‘modifiers’ which modify the current state. The 
class of an operation depends on the ‘position’ of State in its signature: 



constant : 
generator : 
observer : 
modifier : 



Type Type 
Type — > State 
Type X State — > Type 
Type X State -> State 



We assume that the generator init represents the initial state. In the 
simplest Ccise the only types are State and Bool, with constants and 
observers as propositional variables. The first-order model adopts one 
more type, say Nat, and allows operations to take several arguments 
and return results of this type. In the higher-order model operations 
take several arguments and return results of different types. In this case 
Type represents Bool, Nat, Cartesian product of two types etc. 

Type Bool | Nat | Type x Type | . . . 

As a simple illustration consider a component representing a stack. 
The component is represented by the class expression Stacki which con- 
tains definitions of types, signatures and axioms, as below. 



Stacki = class 
type 

State = Elem* 



signatures 




bnd: 


Nat 


init : 


State 


len : 


State — > Nat 


top : 


State — > Elem 


pop : 


State — > State 


push : 


Elem X State State 



axioms 
init = {} 
len(s) = ln{s) 

len{s) < bnd ^ push{e, s) = con{e, s) 
len{s) > 0 pop{s) = tl{s) A top(s) = hd{s) 

end 



Elem is the type of elements we put on stack. The operations are: one 
constant bnd of type Nat, the maximum number of elements on stack; 
one generator init, the state of the empty stack; two modifiers push to 
push an element onto the stack and pop to pop the top element; and two 
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observers top to return the top element and Zen, the number of elements 
on stack. The axioms define the actual behavior of the operations. The 
stack is implemented on the concrete state-space defined as a list of 
elements, with corresponding concrete definitions for operations init^ 
push^ pop^ top and len. They apply the standard list functions con 
(construction), hd (head), tl (tail) and In (length). 

For the purpose of this paper we consider such components in isola- 
tion, as individual objects. On the other hand, to build an application 
we may need a richer component including a collection of objects [10]. 
This would be also the right level to introduce fault-tolerance, batsed on 
the error-detection on the lower level (individual objects). 

3. FAULT-FREE VERSUS FAIL-STOP 
COMPONENTS 

A generator is a typical algebraic operation to construct state values 
[13]. An observer is a co-algebraic operations for making the observations 
about the state [3]. A modifier is both an algebraic operation and co- 
algebraic. This casting of components into an algebra (a carrier set with 
functions into this set) or a co-algebra (a carrier set with functions from 
this set) provides the means to describe how the concrete execution of 
a component unfolds. Here we are interested in the opposite: how to 
abstract away from such concrete executions in order to describe how 
the component should behave in the first place. 

For instance for the stack component we put forward five axioms: the 
length of init is zero, pop decrements and push increments the length, 
top returns the element which was recently pushed onto the stack and 
pop modifies the state back before the last push. All axioms except the 
last relate readers and writers, involving equality over Nat or Elem. 
The last relates two writers and involves equality over the type State. 

Stacko = class 
type 
State 
signatures 
bnd : Nat 

axioms 

len(init) = 0 

len(s) > 0 len{pop{s)) = len{s) — 1 

len{s) < bnd len{push{e^ s)) = len{s) + 1 

len{s) < bnd => top(push(e, s)) = e A pop(push(e, s)) = s 

end 
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Once we described the component on the abstract (Stacko) and con- 
crete (Stacki) levels, we should be able to verify that the concrete com- 
ponent is fault-free. The proof has to demonstrate that concrete def- 
initions satisfy all axioms described by the specification, which boils 
down to proving first-order properties about concrete value domains. 
For instance, len{s) < bnd => top{push(e^ s)) — e has to first expand 
definitions of push and top and then apply a simple fact about lists. 



len{s) < bnd top{push{e, s)) = e 
len{s) < bnd => top{con{e^ s)) = e 
len{s) < bnd => hd{con{e^ s)) = e 
len{s) < bnd e = e 

len(s) < bnd true 

true 



However, this static verification is very often impossible, given the 
requirements for the availability of an implementation, its specifications 
and the feasibility to carry out the proof. The stack example was chosen 
to provide a demonstration with a minimum of the technical details, 
however such details would certainly complicate any more realistic proof. 

Suppose instead of proving that the component is fault-free, we want 
to make sure that faults, after they occur, do not spread out uncontrol- 
lably. That we detect the errors as soon as they occur, and then make 
this fact known to the environment by a boolean observer error. 



error : State Bool 



We call such a component Tail-stop’. A fail-stop component need not 
be fault-free but a fault-free component is certainly fail-stop, only it 
will never experience a failure and its error indicator is permanently set 
to false. We can verify that the component is fail-stop, with respect 
to a given specification, by proving that it is fault-free with respect to 
the weaker Tail-stop specification’. We obtain such a specification by 
syntactic transformation from the original specification, adding error 
to its signatures and modifying the axioms to include the possibility of 
them being violated. We only require that the value of error is true in a 
given state iff at least one of the original axioms is violated in this state. 
When the axioms involve more than one state then we only require this 
property about the last state, provided none of the prior states have set 
error to true. Stack2 below describes such a fail-stop version of Stacki. 
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Stack 2 = class 
type 
State 
signatures 
bnd : Nat 

init : State 

error : State -> Bool 

axioms 
true => 

{len{init) = 0) -yerror{init) 

-^error{s) A len{s) < bnd 

( len{push{e^ s)) = len{s) + 1 

top{push{e^ s)) = e 
-terror (s) A len{s) < bnd A -terror {push{e^ 5 )) => 

/ pop{push{e,s)) = s \ 

I A I -<error{pop{push{e, s))) 

\ len(pop (. . .)) = len(. . - 1 ) 

end 

Although we could try proving directly that the component satisfies 
the fail-stop specification, this would not solve om problems, nor utilize 
the special form of such specifications. Instead, we would like to guar- 
antee the satisfaction of the fail-stop specification by run-time checking. 
We now describes a specification method to make such checking possible. 



^ ->error{push{e, s)) 



4. FAIL-STOP COMPONENTS BY 
PATTERN-MATCHING 

Run-time checking is only possible if the specification method allows 
it to be automated - checking automatically if a given behavior com- 
plies with the specification. However, specification methods are usually 
designed in order to be expressive, to enable abstraction and support ef- 
fective reasoning, not to allow automatic checkability. In particular, we 
cannot check specifications which contain quantifiers (over infinite types) 
and we cannot check equality between states {pop{pusb{e, s)) = s). 

In the sequel we discuss and illustrate five methods, with increasing 
expressive power, to specify software components. All allow run-time 
checking, based on the component’s execution history. 
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4.1. INVARIANTS 

The first specification is a simple propositional formula built from the 
constant /observer operations, playing the role of propositional variables. 

invariant ::= 

constant | observer [ 

-^invariant | invariant V invariant . . . 

The specification is required to hold invariantly for every state in the 
execution sequence, represented by the symbol s. Note the difference 
between constants and observers and how they depend on the state. 

s 1= con iff con 

s \= obs iff obs{s) 

s [= -linv iff not s |= inv 

s 1= invi V inv 2 iff s |= invi or s |= inv 2 . . . 

Consider two example invariants for the stack component: the length 
of the stack never exceeds the bound and if the last operation was push 
then the value of top equals the argument to push: 

len < bnd 

op = push A top = arg 

The first is the first-order formula, written with a relation over Nat. 
The second is the higher-order formula where op returns the name of 
the Icist state-changing operation and arg gives the arguments to this 
operation. The first and higher orders are explained later. 

4.2. ACTIONS 

Invariants allow us only to formulate properties about individual states, 
to hold statically over the whole execution. In contrast, an action is a 
propositional formula over pairs of states. It is built from constants and 
two kinds of observer operations: evaluated in the first state (a pre-state) 
and in the second state (a post-state), the latter written with a prime. 
A pre-state is the state before the execution of a generator /modifier 
operation, a post-state is the state after the execution. 

action ::= 
constant | 

observer \ observer' 1 
-^action I action V action . . . 
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The action is required to hold over any pair of adjacent states in the 
execution sequence, here represented by the symbols si and S 2 - Note 
that observers without prime refer to si and observers with prime to S 2 ] 
constants refer to none. 



Sl, 


52 


N 


con 


iff 


con 


Si, 


52 


N 


obs 


iff 


obs{si) 


Sl, 


52 


h 


obs' 


iff 


obs{s2) 


Sl, 


52 


N 


->act 


iff 


not sl, s2 1= act 


Sl, 


52 


h 


acti V act 2 


iff 


51,52 f= acti or sl,s2 \= act 2 



Consider two example actions for the stack component: a push oper- 
ation increments the length of the stack, provided the stack is not full, 
and a pop operation decrements the length, provided the stack is not 
empty. Written as higher-order actions: 

len> 0 op' = pop A leul = Jen — 1 

Jen < hnd op' = push A leu! = Jen + 1 

4.3. PATTERNS 

Actions will not suffice for specifying those components which correct 
behavior in a given state depends not only on the observations in this 
and the preceding state but also the states before. For instance to check 
for a stack if the value returned by top is correct (if not just inserted) 
we have to find the most recent state in the history in which the value 
of len equals the current len value, then check if the top value in this 
state and the value of top in the current state are the same. Here the 
length of the search depends on the value of an observer. 

The idea is to use regular expressions, similar like for specifying words 
over an alphabet, but the alphabet are vectors of observer values and 
words are sequences of such records (histories). A pattern is a regu- 
lar expression build with usual operators + (sum), • (concatenation), 
* (Kleene’s star) and A (empty sequence), which basic components are 
invariants and actions. 

pattern ::= 

[invariant] | [action] | 

pattern + pattern \ pattern • pattern | pattern* 

The operators have the usual interpretation over sequences (histories). 
We denote such a history by the symbol t and its elements by s, as before. 
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Special role in the evaluation plays the first element in the history, hd{t) 
(if one exists), which is used to evaluate all primed observers in action 
components of the pattern. If t is empty then the only satisfied pattern is 
A, otherwise we use the head of t as well as t itself to carry out evaluation 
hd(t)^t 1= pat. 

, i_ j pat = X if ln{t) = 0 

t pat lit I ^ ^ Q 

In general, evaluation takes the form s^t \= pat where s is a given state 
and Hs a sequence of states, depending on the shape of the pattern pat: 

1 pat — A 

Then t must be empty. 

2 pat = [inv] 

Then t must consist of only one state which satisfies inu, as in 
Section 4.1. However, this state is not necessarily the most recent 
state but any state in the history, as determined by the matching 
process. Also the same invariant may be used a number of times 
against different states. 

3 pat = [act] 

Then t must consist of only one state, such that s and this state 
satisfy act, as in Section 4.2. Primed observers always refer to s and 
unprimed to hd{t). Unlike before, those states are not necessarily 
adjacent in the history: the post-state is always the most recent 
state (s), the pre-state is the currently matched state {hd{t)). The 
action can also be used many times against different pairs of states; 
the same post-state, different pre-states. 

4 pat = pati + pat 2 

Then s and t must either satisfy pat\ or pat 2 ^ or both. 

5 pat = pat\ • pat 2 

Then it should be possible to split t into some t\ and t 2 such that 
s and ti satisfy pati and s and t 2 satisfy pat 2 - s remains the same 
in both cases, providing the same interpretation for the primed 
observers in the actions. 

6 pat = pat* 

Then either t is empty or can be split into ti and t 2 such that s 
and ti satisfy pat\ and s and t 2 again satisfy pat\. Like above, s 
is the same in both cases. Note that the same pattern appears at 
both sides of the definition. 
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Formally, we define the relation 5, t |= pat as follows: 



s, t 1= A iff 

s,t|=[inv] iff 

1= [act] iff 

s, t 1= pat I + pat2 iff 

s, t f= pat I • pat2 iff 

s^t\=pati iff 



Jn(t) = 0 

ln{t) = 1 A hd{t) 1= inv 
ln{t) = 1 A s, hd{t) 1= act 
s, t 1= pati V s, t (= pat 2 
^tijt2 t — ti : t2A 

^7 h h= A s, t 2 h= pato 
ln{t) = 0 V 3t^^t2 t = ti : t 2 A 

^5 h H A s, t 2 1= pat* 



We carry out pattern-matching with every modification of the history, 
i.e. after invocation of every modifier/generator operation, from the 
most recent state towards the initial state. If we can run successful 
pattern-matching with every modification of the component’s execution 
history then it means that up till now the component behaved in a proper 
way. In other words every non-empty suffix of the execution history must 
satisfy the pattern to regard the component as behaving correctly. As 
an example consider the pattern below. 



[aW b] + [aW b] • [a ->6]* • [c' a V 6] 



It says the following: either the history contains only one state such 
that a V 6 holds, or at least two states such that a V 6 holds in the last 
state, aV6 in the first state equals c in the last, and a -^b holds for all 
intermediate states (if any). Matching this pattern against the history is 
shown below. We can see that the pattern is satisfied for all non-empty 
suffixes until state three. However, the value of a V 6 in the first state is 
different than c in the fourth state, thus the pattern is not satisfied by 
the history suffix containing the states one to four. 
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4.4. FIRST ORDER PATTERNS 

We now demonstrate how to extend such specifications into first- and 
higher-order patterns. Suppose first-order specifications allow for ob- 
servers which return integer values. This change will not directly affect 
patterns but their elements, it is invariants and actions. They are both 
build from integer expressions involving literals, arithmetic operators, 
observer names with or without prime, relations between expressions and 
propositional connectives. Such first order specifications are matched 
against the history table which contains integer values. 

As a simple illustration, consider the first-order extensions to concrete 
invariants, actions and patterns, as below, and how they are matched 
against the execution history. The invariant is matched successfully for 
every state until it fails in state eleven. The action is matched success- 
fully for every pair of states until it fails for states eight and nine. The 
pattern is matched successfully for every non-empty suffix of the history 
until and including state five, but it fails in state six. 




4.5. HIGHER ORDER PATTERNS 

With higher order patterns we allow observers of any type. Each type 
comes with its own set of functions and relations. We also assume two 
special observers: op returns the name of the generator/modifier invoked 
to obtain the current state (initially op = init) and arg returns the set 
of arguments this generator/modifier was invoked with (if any). Prom 
now on, we will also assume a [true]* trailer for any regular expression 
used: any prefix of the execution history can be used to satisfy the 
pattern, rather than the whole history. 
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As an example consider a higher-order pattern for specifying the stack. 
We have the usual observers top and len which come with the definition 
of the stack and two generic observers op and arg. op returns the name 
of one of the three possible modifier/generator operations: init^ push or 
pop, arg returns the argument used for the invocation, only relevant if 
op = push. By X we represent that the observer value is not available. 

op : State {init^push^pop} 
arg : State Elem U {x} 

The pattern includes three possibilities: if the state was produced by 
init then len must be zero; if the state was produced by push then top 
is the same as the argument of push and len in the previous state equals 
len in the current state minus one; if the state was produced by pop then 
len in the previous state equals len in the current state plus one, and 
the value of top in the most recent state with the same len value (in all 
intermediate states the value of len is greater than in the current state) 
is the same as the current top value. 

[op = init A len = 0] + 

[op = push A top = arg] • [len = ien' — 1] + 

[op = pop] • [len = len' + 1] • [len > len']* • [len = len' A top = top'] 

Below we describe how this pattern can be matched against a concrete 
history where values put on the stack are real numbers. If the entry 
contains x then it means that the value of a given observer was not 
available, for instance arg = x when the corresponding operation op 
does not take any arguments or top = x when the stack is empty. The 
pattern is satisfied until and including state nine but is violated for the 
state ten: the top value is 2.14 and len is 1 but the most recent state 
with the same value of len has top = 1.0. 
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5. EXAMPLE: LINE EDITOR 

As an illustration of patterns, consider the example of a line editor. 
The editor provides some basic operations to modify the list of elements 
depending on the position of a caret. The position can be inside the 
line and one past the last element (to insert at the end). We have one 
generator init which makes the line empty and sets the caret position 
at one. Four modifiers: right moves the caret forward, if inside the 
line, left moves the caret backward, if not on the first position, insert 
inserts an element at the current position then moves the caret forward, 
and delete deletes an element at the current position, if inside the line. 
Three observers: In returns the length of the line, ps returns the current 
position of the caret (a natural number) and ch returns the element in 
the line on the current position, if inside the line. Here are the signatures: 

type signatures 

State, Elem init : State 

insert : Elem x State State 
delete, left, right : State — )► State 
In, ps : State — > Nat 
ch : State Elem 

The pattern defining the behavior of the editor is a sum of five pat- 
terns, depending which modifier /generator operation was executed last: 

pat-init + pat-insert + pat-delete + pat-right + pat-left 

pat-init only requires that the position value becomes one and the 
length becomes zero in the state resulting from the execution of init. 
The previous state, if any, is not consulted (no primed observers): 

pat-init =def [op = init A ps = 1 A Jn = 0] 

pat-insert requires that the value of the position and length after 
the execution of insert both increase by one, and the character under 
caret remains the same, but only if the caret is inside the line (we avoid 
applying the observer ch when the caret does not point at any character). 

pat-insert =def [op = insert]- 

[Jn' = in + 1 A ps' = ps + 1 A {ps < In ^ ch' = ch)] 

pat-delete breaks into three cases, depending if the current position, 
after the execution of delete, is greater, equal or less than the length. If 
greater then we only require that position and length remain unchanged. 
If equal then the position must be the same and the length must decrease 
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by one, this is when we just deleted the character on the last position 
in the list. In both cases the resulting position is outside the line, so 
we are not interested in the value of ch. If less then the position must 
not change and the length must decrease, like before, but we also search 
the history to find the value corresponding to cb. We look for the state 
where the caret position equals the current one, only counting from the 
end of the list. This is because prior to delete, the caret was on the 
left of the current character, so the list could be modified. We look for 
the first state which position hcis the same distance from the end of the 
list as the current position. In — ps = In! — ps' , where we check that the 
character under caret and the current character are the same. 

pat-delete =def [op = delete]- 

/ [ps' > In' A ps' = ps A In' = ln]+ \ 

[ps' = In' A ps' = ps A In' = In — 1]+ 

[ps' < In' A ps' = ps A In' = In — !]• 

\ [In — ps > In' — ps']* [In — ps = In' — ps' A ch' = ch] J 

pat-right is similar to pat-delete. It breaks into three cases for the 
value of position which is greater, equal or less then the length. Position 
must increase, provided inside the line, and the length remains the same. 
We look for the value of the current character like we did for pat-delete, 
counting the distance from the caret position to the end of the line. 

pat-right =def [op = right]- 

/ [ps' > In' A ps' = ps A In' = ln]+ \ 

[ps' — In' A ps' = ps+1 A In' = ln]+ 

[ps' < In' A ps' = ps+1 A In' = lii]- 
V [In — ps > In' — ps']*[ln — ps = In' — ps' A ch' = ch] J 

pat-left has also three cases. The first is when the caret is already 
on the first position, then the length, position and character (provided 
the caret is inside the line) must stay the same. Otherwise the length 
remains unchanged and position must decrease, moreover if the previous 
operation was insert then its argument must be the current character. 
Otherwise we look for: (1) the earliest state with the same position 
value, which character and the current one must then be the same, or 
(2) the state where position is one greater than the current and insert as 
the last operation, in which case the argument to insert and the current 
character must be equal. The complication in this cause is due to the fact 
that insert not only inserts a character but also forwards the caret. 
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pat-left =def [op = 

/ [ps' = 1 A ps' = ps A lif = In A {In' > 0 ch' = ch)]+ ^ 

[ps' > 1 A op = insert A 

ps' = ps — 1 A In' = In A ch = arg]+ 

\ps' > 1 A op ^ insert A ps' = ps — 1 A In' = In]- 
[ps > ps' A (ps = ps' + 1 op 7 ^ insert)]*- 
[ps = ps' A ch' = chW 

\ ps = ps' + 1 A op = insert A ch' = arg] 

One comment is in place. This pattern may appear complicated, given 
a rather simple component it is supposed to check. There are two reasons 
to explain this. The first is the fact that we specified the component in 
a complete way, when normally one would like to specify and check 
selected critical properties. The second is the fact that this pattern has 
been defined directly in terms of observers, without the intermediate 
level of auxiliary properties, specially designed to capture reoccuring 
properties. On the other hand, the pattern above is composed of five 
independent patterns which, one can argue, are simple on their own. 
Whatever point of view we adopt, the scalability of the whole approach 
is no doubt an important practical concern, which we plan to address in 
our future work, along with other issues discussed in the conclusions. 

6. IMPLEMENTING THE 

WRAPPER-GENERATOR 

One way to make sure that a given component is fail-stop is to prove 
that it satisfies the fail-stop specification. But this ignores the special 
form of the fail-stop property, and typically requires a fair amount of 
human assistance. Instead, we want to guarantee this property at run- 
time, where a specification is given in the form of a pattern and run-time 
checking is carried out by an automatically generated wrapper. Here we 
discuss the implementation of the wrapper-generator. 

Consider the structure of the wrapped component. The signature is 
the same as that of the original component plus the observer error. 
The state includes some part of the execution history (as necessary for 
checking) and the error indicator. The wrapper takes over all commu- 
nication between the original component and its users. Invocation of a 
constant/observer is passed to the component and obtained results di- 
rectly returned to the user, no checking is done in this case. Invocation 
of a generator /modifier is carried out on the original component, obser- 
vations about the new state and operation itself are recorded. Then we 
carry out pattern-matching with respect to this modified history and set 
the error fiag accordingly. The wrapper may conduct more activities, in 
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particular maintain the history record, remove the observations with no 
effect on future checking etc. Figure 2 depicts this structure. 
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Figure 2 Structure of the wrapped component. 



We would like this wrapped component to be generated automatically 
for a given pattern. We designed a prototype wrapper generator for 
components written in a small subset of Java. The generator is intended 
as a tool for writing case studies on the use of patterns for specifying 
components and pattern-matching for checking their behavior at run- 
time. At this moment there are several constraints we impose on the 
input Java classes: the only data type is natural numbers, modifiers 
take zero or one argument, class constructors take no arguments and 
exceptions are not allowed. The wrapper generator Wrap is itself written 
in Java, using the JavaCC tool to support parsing. The input is the 
specification file that contains the name of the class to be wrapped, its 
signature in a simplified form and the pattern specifying the correct 
behavior of the class. Here is the specification file for the stack: 



#Classname 
NatStack 
#Modif iers 
pushO ; 
pop; 

#Observers 

top; 

len; 



#Actions 

qO = {op = init /\ len = 0} 

ql = {op = push /\ arg = top'} 

q2 = {len = len' - 1} 

q3 = {op = pop} 

q4 = {len = len' + 1} 

q5 = {len > len'} 

q6 = {len = len' /\ top = top'} 



#Pattern 
qO + 
ql.q2 + 
q3 . q4 . q5* . q6 



Wrap produces the source code for the wrapper class, which is a 
subclass of the claiss specified in the input file. The class contains some 
additional variables to store the execution history, the automaton which 
represents the regular expression, error indicator, methods to update 
and check the execution history etc. All observers are inherited from 
the parent class and all modifiers and generators are overridden: call the 
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parent method, update the history record, carry out pattern-matching 
and set accordingly the error indicator. Wrap also creates an applet 
which can be used to test the execution of the produced wrapped class. 
The applet allows to invoke modifiers, individually or in a sequence, 
display the execution history, observer values and indication of an error. 
It also compares the execution times for original and the wrapped class. 

A few comments on the implementation and the use of wrappers. 
As our main purpose is error-detection, we do not consider how the 
wrapped component should be used to build reliable distributed systems. 
This belongs to the next level - implementation of fault-tolerance. One 
idea would be to integrate patterns with a component framework like 
CORBA: make them part of the IDL description of a component, gener- 
ate the code for run-time checking along with the usual stub code, build 
applications which actively inspect the error status for the components 
they are built from. Another idea is to use the wrapper in a remote 
way, as a smart proxy for its component, or as a CORBA interceptor 
to become part of the growing class of objects providing infrastructure 
services for other objects. Whatever method is used, wrappers repre- 
sent the knowledge (refiection) how their components should behave. 
They cannot change how the components behave, but the behavior of 
applications built from such components. 

7. CONCLUSIONS 

We demonstrated how regular expressions can be used to formally 
specify software components, in order to be able to check their behavior 
at run-time. We build such expressions from the propositions about the 
pairs of states of a component, one of which is the current state, another 
is some previous state determined by the checking process. Checking is 
carried out by a specification-generated wrapper, a kind of pattern- 
matching, which produces a fail-stop component [14] from a component 
which may fail in an arbitrary way. We also presented an architecture 
of the wrapped component and the prototype wrapper-generator, for 
components written as Java classes. 

We argue that run-time checking is particularly suitable for open, 
object-based distributed systems. Distribution makes testing such sys- 
tems difficult in general, given the large number of components and many 
possible ways for them to interact. Openness means such systems are 
relatively easy to modify, but also hard to verify. In particular, decid- 
ing at run-time which components should be used (dynamic invocation) 
makes it hard to approach an apriori verification. Openness also means 
the components come from many origins, they may lack proper certifi- 
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cation or make it difficult (being remote or proprietary) to inspect the 
quality ourselves. Moreover, decisions to include a component are based 
on its IDL description, which typically lacks the semantic information 
or describes this semantics in a natural language. Run-time checks pro- 
vide often the only method of protection for the whole system from its 
unsound, unreliable components. The paper showed how to introduce 
such checks in a systematic way, generated from formal specifications. 

This paper is a revised version of [6]. Related work on software spec- 
ification with regular expressions include [2], but the focus is symbolic 
reasoning, not run-time checking. Specification-based testing [12] is an- 
other related area which purpose is mainly analysis (off-line), unlike here 
where we try to improve reliability (on-line). Run-time checks are prac- 
tically implemented in the Java Assert class (of java.lang.object) but 
only to check invariants. One more related area is fault-tolerance [7]. 
Formalization of fault- tolerance has been carried out by several authors, 
e.g. [8, 5], where they explain how to formally specify and verify an 
existing system. Here, in contrast, we provide a constructive approach 
to actually build such systems, the wrapper-generator, although for now 
we focus only on error-detection. 

We plan to continue this work in several directions. First, we plan 
to produce some real-life case studies for specifying components with 
patterns. Among others we look at the components described in the 
CORBA services documents. Based on such case studies we intend to 
study how the approach scales up. Another direction is to further in- 
vestigate the foundations for run-time checking: we continue to look at 
co-algebras, with their approach to specification of classes [4], but also 
at the alternating automata [1]. It remains to see how we can relate pat- 
terns to the more abstract algebraic or co-algebraic specifications, and 
how to define refinement between patterns according to their strength. 
We also plan to study how run-time checking with pattern-matching 
can be used to build fault- tolerant systems, in particular how to verify 
fault-tolerance on the system level [5] based on the run-time checking on 
the component level. This could provide a demonstration how symbolic 
and run-time techniques can work together. Then there are real-time 
and memory requirements for the whole scheme to work in practice. It 
must be possible to analyze patterns to see which parts of the history 
we have to remember for future checking and which we can discard. At 
best we would like to analyze patterns statically in this respect, at worst 
include some run-time mechanisms like garbage collection. We also want 
to analyze patterns with respect to the performance overheads. 
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Abstract; CORBA is a standard proposed by the Object Management Group (OMG) that 
promotes interoperability between distributed object systems. Following the 
standardization of this object-oriented middleware, the OMG has specified a 
set of Common Object Services (COS) that are meant to serve as the building 
blocks of distributed CORBA applications. The COSes are specified using 
CORBA Interface Definition Language (IDL), that describes the syntactic 
aspects of services supported by remote objects. However, CORBA-IDL does 
not support specification of the behaviour of objects in an abstract and formal 
way, and behavioural specification is mostly provided in plain English. To 
overcome this problem, we have proposed a formal description technique 
(Cooperative Objects) based on high-level Petri nets, and developed a software 
support environment. The goal of this paper is to demonstrate that our 
approach is suited to the formal specification of typical CORBA COS, and 
presents a Cooperative Object model of the CORBA event service, a COS that 
provides asynchronous, one-to-many communication between objects. The 
advantages of dealing with a tool-supported, executable formal notation are 
detailed, as well as the results that can be obtained through Petri net analysis 
techniques. 

Key words: Distributed systems, behavioural specification, CORBA, high-level Petri nets. 



1. INTRODUCTION 

CORBA [15] (Common Object Request Broker Architecture) is a 
standard proposed by the Object Management Group (OMG) in order to 
promote interoperability between distributed object systems. CORBA 
mainly defines a common architecture for an Object Request Broker (ORB) 
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and an Interface Definition Language (IDL). An ORB provides the 
middleware necessary to locate server objects on the network, and to route 
invocations between clients and servers regardless of the programming 
language they are written in. To achieve this goal, the CORBA standard 
requires the use of IDL for describing the interface of remote objects. The 
IDL defines basic tjqies (short, float,...), structured types (struct, sequence, 
array. . .) and provides signatures of operations for interface types. 

1.1 The CORBA Services 

The OMG has specified a set of common object services (COS) in a huge 
document: the CORBA COSS (Common Object Services Specifications) 
[16]. The CORBA services are designed to be the building blocks of large- 
scale CORBA applications and have the stated goal of promoting 
interoperability, as they give standardised solutions to commonly 
encountered problems. Among typical COS are the CORBA Naming Service 
(that allows to retrieve a remote object reference by providing a symbolic 
name) and the CORBA Event Service (which allows event-based 
asynchronous communication using events). 

The specification of the CORBA services is mainly provided by the 
OMG in the form of a mixture of IDL (for the definition of the interfaces) 
and English text (for the specification of the behaviour). The COSes do not 
contain an integrated behavioural description and, as a result, are sometimes 
inaccurate and ambiguous. 

Moreover, the COSS are sometimes left deliberately underspecified. This 
has been a choice of the OMG to leave "quality of service" issues out of the 
specifications, in order to leave flexibility to the implementers of services. 
However, in our opinion, this form flexibility has in several occasions gone 
so far as to hinder interoperability between distinct implementations. 

Furthermore, the OMG does not provide test suites that would allow 
checking the conformity of implementations. Therefore, developers working 
in companies producing implementations of the COS have to overcome 
those inaccuracies and underspecifications using their own experience. As a 
summary, despite the clear objectives of CORBA, the specification leads to 
potential interoperability problems. 

1.2 Formal specification of CORBA systems 

In the framework of the SERPICO project, we have developed a formal 
notation suited to the behavioural specification of CORBA systems: 
Cooperative Objects (CO) [7], [8]. CO are an object-oriented dialect of high- 
level Petri nets that allow describing the behaviour of a collection of 
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distributed objects. The usefulness of combining Petri nets and objects has 
been recognised by several authors [1;2;10]. The CO notation is supported 
by a software tool called PetShop [9] that allows for the interactive editing, 
execution and analysis of specifications. 

The present paper aims at showing that the Cooperative Objects 
formalism can provide a suitable solution to the problem of behavioural 
specification of distributed objects, in the context of CORBA. Moreover, we 
want to show that this formal specification technique is scalable enough to 
cope with large specifications such as the CORBA Event Service. The paper 
is organised as follows: we present in section 2 the Cooperative Objects 
formalism and how it fixlly supports the CORBA model. Section 3 gives an 
overview of the CORBA Event Service, that is formally specified in 
section 4. Section 4 also shortly describes the kind of model analysis and the 
PetShop environment that supports CORBA system modelling. Section 5 
describes the ongoing work and concludes the paper. 



2. THE CO FORMALISM 



The Cooperative Objects (CO) [5] formalism is a dialect of object- 
structured, high-level Petri nets. The object-oriented approach provides the 
concepts necessary to define the structure of objects and their relationships 
in order to specify the system according to the principles of strong cohesion 
and weak coupling; the theory of Petri nets provides the specification of the 
behaviour of objects and of their inter communications, so that we can 
express both the concurrency between different objects and the internal 
concurrency of an object. 



Ilnttirfac* Buffer { 

void put tin atringr m) ; 
string get { ) ; 

1 ; 



Syntactic viewpoEnt ■ 
IDL interfAce 




Behavioural Specification: 
High level Pclrl net 



Figure 1. The Cooperative Object class BufferSpec 
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A CO class is the combination of a CORBA-IDL interface and of a high- 
level Petri net (the Object Control Structure, ObCS) that specifies the 
behaviour of the interface {Figure 1). In the ObCS, tokens are allowed to 
contain references to other objects of the system. As the behaviour of the 
objects is defined in terms of Petri nets, we obtain a set of Petri nets that are 
mutually referenced. 

2.1 Overview of definitions of COs 

The complete formal definition of CO has been provided in previous 
publications [8], [17], and we will only recall informally their main features. 
The aim of this presentation is to allow the reader to understand the models 
in the following sections. CO can be considered as a mapping fi'om CORBA- 
IDL to high-level Petri nets. More specifically: 

- The type system (TypeSet) of the ObCS is defined in terms of CORBA- 
IDL. Variables having an IDL interface type are called references; 

- Tokens are tuples of typed values. The arity of a token is the number of 
values it holds, and tokens of zero-arity are thus the “basic” tokens used in 
conventional Petri nets. We will call Token-type a tuple of types, 
describing the individual types of the values held by a token. Token-types 
are noted <Typei,... Typen> or just <> to denote the Token-type of 
zero-arity tokens; 

- Places are defined to hold tokens of a certain Token-type; thus all tokens 
stored in one place have the same Token-type and arity. A place holds a 
multiset of tokens; thus a given token may be present several times in the 
same place; 

- Each arc is labelled by a tuple of variables, with a given multiplicity. The 
arity of an arc is the number of variables associated to it. The arity of an 
arc is necessarily the same as the arity of the Token-type of the place it is 
connected to, and the type of each variable is deduced from this Token- 
type. The multiplicity of an arc is the number of identical tokens that will 
be processed by the firing of a transition associated to this arc. The general 
form of an arc inscription is mul t ipl i c i ty * <vl , ... vn>; 

- Transitions have a precondition (a Boolean expression of their input 
variables) and an action, which may use any operation allowed for the 
types of their input or output variables. The scope and type of each 
variable of an arc is local to the transition the arc connects to. 

Enabling rule. A transition is enabled when: 

- A substitution of its input variables to values stored in the tokens of its 
input places can be found; 

- The multiplicity of each substituted token in the input places is superior or 
equal to the multiplicity of the input arc; 
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- The precondition of the transition evaluates to true for the substitution. 

Firing rule. The firing of a transition executes the transition’s action, 
computes new tokens and stores them in the output places of the transition. 
The formalism also supports two arc extensions [13]: test arcs and 
generalised inhibitor arcs. 

2.2 Mapping CORBA-IDL to high-level Petri nets 

We now illustrate the CO-CORBA integration by showing the CO class 
BufferSpec that specifies the behaviour of the interface Buffer, described in 
Figure 1. 

Mapping for services. Each service op defined in an IDL interface is 
mapped to two places in the ObCS net: a Service Input Port (SIP, labelled 
op), and a Service Output Port (SOP, labelled op). These two places are 
derived from the IDL, as follows: 

- The Token-type of the SIP is the concatenation of the IDL types of all in 
and inout parameters of the service; 

- The Token-type of the SOP is the concatenation of: 

a) the IDL type of the result returned by the service (if any); 

b) the list of the IDL types of all out and inout parameters of the service. 

The invocation of one service results in one token holding all in and inout 
parameters being deposited in its SIP. The role of the ObCS net is to process 
this parameter token in some way, and eventually deposit a result token 
(holding the result of the service, plus all out or inout parameters) in the 
SOP, thus completing the processing of the invocation. An invocation can be 
interrupted by the occurrence of an exception, which is modelled by a 
special exception transition. 

Figure 1 shows the CO class BufferSpec that displays an ObCS and some 
textual annotations. These textual annotations are: 

- The list of the interfaces that the CO class specifies (keyword specifies). In 
this case, the BufferSpec class specifies the Buffer interface; 

- The description of the places’ token type: for example, the token type of 
Messages is <string> and corresponds to the data inserted in the buffer; 

- The description of the transitions’ preconditions and actions, if any. Only 
the transitions with non-default precondition or action need to be stated in 
the textual part. 

The ObCS in Figure 1 complements the CORBA IDL part by providing a 
sensible behavioural specification. The Petri net provided specifies an 
imbounded buffer, where the order of message extraction is done in a non- 
deterministic way. In this specification, operations put and get may occur 
concurrently (in terms of Petri nets, transition T1 and T2 are not conflicting). 
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The net also describes a blocking semantics for the get operation: the client 
of the get operation is blocked until a message is available (i.e. until the 
transition T2 is enabled to fire). Alternative behaviours (such as bounded 
buffer, FIFO extraction or non-blocking operations) could be specified just 
as easily. 

The CO formalism distinguishes three kinds of transitions. All are used in 
the specification of the CORBA Event Service in §4: 

- Invocation transitions that are used to invoke CO instances. The action of 
an invocation transition is the invocation of a service offered by another 
object; 

- Instantiation transitions that are used to create instances of a CO class; 

- Exception transitions that interrupt the normal processing of a service. 

The semantics of these three kinds of transitions is defined in terms of 
Petri nets [5], which allows to have a Petri net based semantics for a system 
of communicating objects, and not only for a single isolated object. A 
denotational semantics for the Cooperative Objects formalism is defined in 
[5]. This shows that object-oriented concepts such as instantiation, 
inheritance and dynamic binding can be formally represented within the 
framework of Petri nets theory. The basic principle of this denotational 
semantics is to construct a single, static high-level Petri net Ifrom the ObCS 
of all the classes involved in a specification. 



3. OVERVIEW OF THE CORBA EVENT SERVICE 

Formal specification techniques are sometimes criticized on the grounds 
that they deal properly only with small-scale examples (such as the Buffer 
illustrated in Figure 1). The goal of this paper is to demonstrate that our 
approach scales well and allows one to tackle real-life specifications such as 
the COSS. 

Among the fourteen services of the CORBA COSS [16], we have 
selected the CORBA Event Service for the following reasons: 

- It is "self contained": it does not use any other service defined in the 
COSS, unlike many COSes that rely on other COSes for their definition or 
operation. For example, the Life Cycle Service uses the Naming Service. 
Besides, the CORBA Event Service does not rely on functionalities 
defined by CORBA like the Interface Repository. It is therefore possible 
to specify completely the CORBA Event Service without making any 
hypothesis on underlying services; 

- It is complex due to its versatility. In particular, the connection to the 
event channel uses a non trivial protocol between event consumers and 
event suppliers; 
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- Most ORB vendors implement it. This is not the case for the majority of 
COSes: in fact the OMG has standardised some services for which there is 
not enough demand yet. Therefore the developers are not inclined to 
implementing all COSes. 

3.1 Presentation of the CORBA Event Service 

The CORBA Event Service ([16], Chap. 4 ppl-33) provides 
asynchronous, "one-to-many", event-based communication, using an event 
channel that allows decoupling event suppliers from event consumers. This 
goes beyond the synchronous and "one to one" client-server invocations 
supported by CORBA, where the client object must always hold a reference 
to the object to be invoked. 

The Event Service defines two communication models according to who 
takes the initiative of the communication of events: 

- The push model in which the consumer is passive and the supplier is 
active. The latter holds a reference to the consumer and invokes the 
consumer's methods for event transmission; 

- The pull model in which the consumer is active. It holds a reference to the 
supplier and requests events from the supplier. 

Orthogonal to the two models of communication, two types of event 
channels are distinguished; 

- The generic event channel that transports events of IDL type any. This 
type is a self descriptive type and allows the transportation of all kind of 
events by encapsulating them in a value of type IDL any, 

- The typed event channel that transports events of a specific IDL type. 
That mode of transportation allows efficient processing for consumers that 
no more have to analyse a value of type any. 

3.2 Interfaces and roles 

CORBA Event Service is "t 5 q>ically decomposed into several distinct 
interfaces that provide different views for different kinds of clients of the 
service"([16], p. 2-2). However, the term client is misleading in a client- 
server context because it infers that only the server is invoked. Therefore we 
use the term customer to refer to the clients of the CORBA Event Service 
because the event channel is a client or a server according to the interface it 
shows. 

In this paper, we detail only the generic event channel in push model. As 
such, the service is defined in two modules and seven interfaces. These 
interfaces are described in Figure 2 and Figure 3 using UML notation. 
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CORBA Event Service defines three main roles: 

1 . The channel administrators; 

2. The event supplier; 

3. The event consumer. 



management 
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Figure 2. Interfaces of the channel administrators in the push model 

Channel administration occurs at two levels: 

- Management of event channel availability. The EventChannel interface 
designates an event channel and is the lead administrator that decides on 
the availability of the event channel (operation destroy) and provides 
connection administrators for the customers of the event channel 
(operations obtain_supplier_admin and obtain consumer admin ). ; 

- Management of connections to the event channel. Administrators are 
subdivided in two groups according to the event channel customers they 
care about: the SupplierAdmin interface allows the supplying customers of 
the channel to obtain a view of the channel that receives the events 
produced by the customers (operation obtain _push_consumer). The 
ConsumerAdmin interface allows the consuming customers to obtain a 
view of the event channel that supplies events to the customers (operation 
obtain _push supplier). 



customers 
of the 

event channel 



views 
of the 

event channel 




Event suppliers 
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Figure 3. Interfaces of the event suppliers and consumers in the push model 
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The PushSupplier interface designates a supplier of events. The operation 
disconnect _push_supplier allows the disconnection of the communication 
between a consumer and a supplier. The ProxyPushSupplier specialises the 
PushSupplier and is the view presented to a customers of the event channel 
that is a consumer of event. 

The PushConsumer interface designates a consumer of events. The 
operation disconnect _push_consumer allows terminating the communication 
between a consumer and a supplier. The ProxyPushConsumer specialises the 
PushConsumer interface and is the view of the channel presented to a 
customers of the channel that is a supplier of events. 

3.3 A scenario of use of the event channel 

Figure 4 shows a typical scenario of use of the event channel in push 
model. An object (Receptor) wishes to subscribe to an event channel and 
play the role of a consumer of events. Another object (Emitter) wishes to 
subscribe and play the role of a supplier of events for the same event 
channel. The objects Emitter and Receptor connect to the event channel 
independently and without informing each other. The event channel plays 
the role of buffer between the consumer and the supplier, and connects each 
of its customers (Emitter and Receptor) to a proxy, by following a well 
defined, four steps, connection protocol: 




Figure 4. Scenario of use of the event channel 

1. Emitter and Receptor obtain a reference to the event chaimel (for 
example, by using a name server to obtain a reference to an EventChannel 
object named "Channel"). The reference found is denoted EC\ 

2. Emitter and Receptor ask EC the references to an appropriate 
administrator and obtain respectively a reference to an administrator of 
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suppliers {SAd, by invoking for suppliers) and an administrator of 
consumers {CAd, by mwdkmg for consumers)-, 

3. SAd returns a ProxyPushConsumer (PPushCons) to Emitter upon 
invocation of obtain _push_consumer and CAd returns a proxy supplier 
(PPushSup) to Receptor upon invocation of obtain _push_supplier, 

4. The connection is established between the event channel and its customers 
after the invocation of the operations connect _push supplier on 
PPushCons by Emitter and connect jjush consummer on PPushSup by 
Receptor. The latter invocation requires one parameter that is the 
reference to a consumer (consRef), delegated by Receptor, so that the 
proxy supplier PPushSup can invoke the operation push when events are 
available. 

The communication takes place by invoking the operations push on the 
consumers at the entrance of the channel (left side of Figure 4) due to the 
supplier supRef delegated by Emitter, and at the exit of the channel due to 
PPushSup (right side of Figure 4). The communication can be stopped by 
invoking the disconnection operations provided by the PushConsumer and 
PushSupplier interfaces of supRef, consRef, PPushCons and PPushSup, or 
by destroying the event channel EC. 

The transportation of events from proxy to proxy is not specified by the 
OMG and is left out to implementers. We modelled that transportation with 
an operation handleEvent in the case of the push model. When supRef 
transmits the event myEvent as parameter of the push operation to 
PPushCons, the latter invokes handleEvent on ChannelServer in order to 
route the message to all ProxyPushSupplier objects, like PPushSup. Lastly, 
PPushSup invokes the operation push on consRef with the parameter 
myEvent. We precise the object which supports handleEvent later. 



4. CO-BASED FORMAL SPECIFICATION 

The CORBA Event Service has been designed for maximal versatility, 
but its structure and behaviour are far from being trivial and intuitive. 
Therefore, we first present specification process we went through before 
giving its formal specification. 

4.1 Voluntary or involuntary specification 

The OMG's specification of the CORBA Event Service is voluntarily 
incomplete: In particular it does not state the quality of service a conforming 
implementation should have. For example, the OMG specification does not 
impose a reliable transmission of events through the event channel; events 
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may be lost or duplicated. Paradoxically, the OMG's specification says that 
"Clearly, an implementation of an event channel that discards all events is 
not a useful implementation". 

As we wish to provide an accurate behavioural specification of the event 
service, we need to go further than the COSS does: with respect to the OMG 
document, we will provide an overspecification of the event service, in that 
we specify an event service that does not lose nor duplicate the events. 
Obviously, any implementer of the event service chooses to implement a 
given quality of service, and is supposed to document this choice to his 
customers. In the actual implementations we have experienced, however, 
this information is hardly ever provided. 

4.2 Management of ambiguities in the initial 
specification 

As the starting point of our specification is a dociunent in natural 
language, we were expecting to find underspecifications (involuntary ones 
this time), ambiguities and even contradictions. The objective of the formal 
specification is precisely to detect such flaws in the initial specification and 
to correct them. In the process of our specification, we effectively detected 
ambiguities and underspecifications; but we detected no contradiction. 

When problems were detected, our attitude was: 

- To document precisely the problem: if we detect the problem during the 
formal specification, it is reasonable to believe that implementers of 
CORBA Event Service will also detect it during implementation, and that 
they will solve it. The fact that we identified a problem will guide us 
during the tests of the real implementations; 

- To complete and precise the specification, choosing among alternatives 
the one that seems to us the most logical, the easiest and the most in 
conformity with the philosophy of the CORBA Event Service. Of course, 
it is an arbitrary choice, and other specifiers might not share our views. 

Figure 5, below, displays the type of imderspecification we have met in 
the COSS. The figure shows an “informal” state diagram of a proxy as 
defined in [16], p.4-14, along with comments in natural language. This 
specification is largely incomplete: the state diagram is not complete as 
many potential state transitions are ignored (for example, what happens 
when the operation "disconnect" is invoked when the proxy is in the state 
disconnected?). On the other hand, the comments made in natural language 
are ambiguous (“operations are only valid in the connected state”: what does 
valid mean for an operation?). 
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Proxies are in one of three states: disc&nnecttd. coveted or destraytd. Figure 4-9 
gives a slate dia^rani for a proxy^ The nodes of the diagntm are the stales and the edges 
ate labelled with the aperaticns that change the state of the proxy, push /pull 
operations are only valid in the connected state. 
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Figure 4-9 State diagram of a proxy 



Figure 5. Excerpt of the OMG’s specification of the CORBA Event Service ([16], p.4-14) 



module CosEventChannelAdmin { 

// original QM6 specification of this module fits here 

interface Router { 

void handleEvent (in any data); 

}; 

interface EventChannelRouter : EventChannel , Supplier Admin, 
ConsumerAdmin, Router { } ; 

interface ProxyPushSupplierExt : ProxyPushSupplier{ 
void deliver (in any data) ; 

}; 

interface ProxyConsumerLi s t { 

void add ( in ProxyPushConsumer s ) ; 
void remove ( in ProxyPushConsimier s ) ; 
void disconnect For All ( ) ; 

}; 

interface ProxySuppl i erLi s t { 

void add (in ProxyPushSupplier s) ; 
void remove (in ProxyPushSupplier s) ; 
void disconnect For All ( ) ; 
void pushForAll (in any data) ; 

}; 

li 



Figure 6. Interfaces added to CORBA Event Service 

In order to deal with the underspecifications stated above, we specify the 
behaviour of an extended CORBA Event Service in which new interfaces are 
added to the module CosEventChannelAdmin that defines the event channel 
(c.f. Figure d). The new interfaces are defined using interface inheritance to 
extend the interfaces previously described in §3.1 in order to specify a useful 
CORBA Event Service. 
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We need essentially to specify how the channel routes the events from 
producers to consumers, and to describe how the service manages the proxy 
objects that it creates dynamically during its operation. We therefore 
introduce a Router interface and specialise EventChannel into 
EventChannelRouter. Thus the operation handleEvent, referred to in §3.3 is 
devoted to an EventChannelRouter. The ProxyPushSupplier is also 
specialised in ProxyPushSupplierExt that receives events (operation deliver) 
from the Kouter and delivers them to its customer. 

4.3 CO-based specification 

The CORBA Event Service has been completely specified using CO, 
faithfully to the OMG specification, in [19]. This paper only presents the 
push model, for space reasons and also because the pull model is very 
symmetric to it, and would not add much to the presentation. We present the 
five CO classes that model the behaviour of: 

- The main interfaces of the event channel: EventChannelRouter Spec, 

ProxyPushConsumerSpec and ProxyPushSupplierExtSpec; and 

- Two helper classes ProxySupplierListSpec and ProxyConsumerListSpec. 

4.3.1 Class EventChannelRouterSpec 

Figure 7, below, shows the class EventChannelRouterSpec that specifies 
the behaviour of the interface EventChannelRouter defined in our extension 
of the OMG’s specification. Place active is initially marked with one token 
{<psl, pcl>} that holds references to two lists of proxies: psl is a 
ProxySupplierListSpec {Figure 9) and pci is a ProxyConsumerListSpec 
{Figure 8). The event channel is ready for operation and can distribute the 
reference to its administrators in accordance to the scenario described in 
§3.3. When the operations forjconsumers (top left sub-net) and 
for suppliers (top right sub-net) are invoked, transitions giveCAd and 
giveSAd return the event channel. 

When a customer requests a ProxyPushSupplier through operation 
obtain _push supplier (middle left), the instantiation transition givePPS 
returns a new ProxyPushSupplierSpec object. When a customer requests a 
ProxyPushConsumer through operation obtain _push_consumer (middle 
right), the instantiation transition givePPC returns a reference of a new 
ProxyPushConsumerSpec object. For the sake of readability, the ObCS of 
Figure 7 does not represent the operations corresponding to the pull model: 
obtain _pull_supplier and obtain _pull_supplier. These operations return a nil 
object reference so that customers of the event channel cannot work in the 
pull model. 
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class EventChannelRouterSpec specifies EventChannelRouter { 
place active cProxySupplierList , ProxyConsumerList> = 

{new ProxySupplierListSpec ( ) , new ProxyConsumerListSpec ( ) } ; 
place destroyed <>; 
transition givePPS{ 
action { 

r = new ProxyPushSupplierSpec (psl ) ; 



transition givePPC{ 
action { 

r = new ProxyPushConsumerSpec (self , pci) ; 



transition pushForAll { 
action { 

psl .pushForAll 0 ; 



transition disconnectForAll { 

action { 

pci . disconnectForAll ( ) ; 
psl . disconnectForAll ( ) ; 



transition tl, t2, t3, t4, t5, t6 { 
action { 

raise new OBJECT_NOT_EXIST ( ) ; 




Figure 7. Class EventChannelRouterSpec 
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The ObCS of Figure 7 also describes accurately how the operation 
handleEvent (bottom left sub-net) handles the routing of events to all 
customers of the event channel. Firing the invocation transition pushForAll 
does the following: 

- It removes an event token from the SIP of handleEvent, that is the routed 
event; 

- It removes the token in place active. Therefore, (1) two events cannot be 
routed simultaneously because the transition pushForAll is disabled; (2) 
no new proxies are added while routing because transitions givePPS and 
givePPC are also disabled; (3) the channel cannot be destroyed while 
routing because transition disconnectForAll is disabled; 

- The action part is executed. The operation pushForAll (bottom left on 
Figure 9) is requested on the ProxySupplierList, psl. 

The firing of the invocation transition pushForAll ends when the request 
on the ProxySupplierList, psl, is completed. A token <psl,pcl> is then 
deposited in the place active and a token o is deposited in the SOP of 
handleEvent, which completes the invocation of operation handleEvent. 

Finally, the ObCS of Figure 7 precises the underspecified behaviour of 
the EventChannel when the operation destroy is requested. The invocation is 
completed when the administrators have been destroyed and all the proxies 
have been disconnected. This choice is implied by the fact that destroy is 
supposed to destroy the event channel; acting differently would allow to use 
the event chaimel after its destruction. 

The event channel switches to inactivity by firing the invocation 
transition disconnectForAll, that requests the operation disconnectForAll 
from the two proxy lists, psl and pci. As soon as these requests are 
completed, the proxy switches to the state destroyed. 

The ObCS of Figure 7 also precises the behaviour of all the operations 
once destroy is requested. All operations will raise the CORBA exception 
OBJECT_NOT-EXIST. Thus customers will realize that the event channel 
no more exists. The transitions tl, t2, tS, t4, t5 and t6 are exception 
transitions: they are labelled with the type of the exception they raise. 

4.3.1. 1 ProxyConsumerListSpec 

ProxyConsumerListSpec {Figure S) objects are responsible for managing 
the set of ProxyPushConsumerSpec objects given to customers of the event 
channel. Operations add and remove allow adding and removing proxies 
from place proxyConsumers. 

Operation disconnectForAll disconnects and removes proxies from the 
set before returning. Firstly, transition disconnectProxyConsumers is linked 
to the SIP of disconnectForAll by a test arc. Test arcs are only involved in 
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the enabling rule, but, unlike input arcs, not in the firing rule; thus the tokens 
involved in the enabling substitution chosen for firing the transition are not 
removed. Therefore, firing disconnectProxy Consumers allows to empty the 
place proxy Consumers, and its action allows to disconnect the proxies. 



class ProxyConsumerList specifies ProxyConsumerList { 
place proxy Consumers <ProxyPushConsumer> ; 
transition disconnect { 

action { 

s . disconnect_push_consumer ( ) ; 

} 




Figure 8 Class ProxyConsumerListSpec 

Secondly, transition kill is linked to the place proxyConsumers by an 
inhibitor arc. Inhibitor arcs are also only involved in the enabling rule and 
do not remove token during the firing: the enabling rule states that the 
inhibitor arc enables the transition kill only if the connected place is empty. 
The occurrence of kill removes the token from the SIP of disconnectForAll 
and puts a token in the SOP of disconnectForAll : the operation returns. 

4.3.1.2 ProxySupplierListSpec 

ProxySupplierListSpec objects play two roles {Figure 9): 

- They manage the set of ProxyPushSupplierExt objects delivered by the 
event channel, exactly like ProxyConsumerListSpec objects do; 

- They are responsible for the effective routing of events to customers of the 
event channel. 

The ObCS of Figure 9 describes how the routing is handled when 
operation pushForAll is invoked. Firstly, all proxy reference tokens are 
selected: they are removed from place proxySuppliers and deposited in place 
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selection (transition selectAll). Secondly, the event token is chosen in the SIP 
of pushForAll (transition begin) and one token is deposited in place routing. 
Thirdly, the operation deliver is invoked once on all the selected proxy 
references (invocation transition deliver). Finally, when all selected proxies 
have delivered the event the operation returns {transition end). 



class ProxySupplierList specifies ProxySupplierList { 
place proxySuppliers <ProxyPushSupplier> ; 
place routing <>; 

place selection <ProxyPushSupplier> ; 
transition disconnectProxySupppliers { 

action { 

s . disconnect_push_supplier ( ) ; 



transition deliver { 
action { 

s . deliver (data) ; 




Figure 9 Class ProxySupplierListSpec 

4.3.2 Class ProxyPushConsumerSpec 

Figure 10 shows the class ProxyPushConsumerSpec that specifies the 
behaviour of the interface ProxyPushConsumer defined by the OMG’s 
specification {Figure i). Initially the place unconnected is marked with one 
token, which indicates that the proxy is not connected to a customer of the 
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class ProxyPushConsumerSpec specifies ProxyPushConsumer { 
place unconnected <ProxyConsumerList> = {l*<proxy>}; 
place router <Router> = {l*<router>} ; 
place connected <ProxyConsumerList> ; 
place destroyed <ProxyConsumerList> ; 
place events <any>; 
transition connect { 
action { 

l.add(self ) ; 



transition disconnect { 
action { 

1 . remove (self) ; 
s . disconnect_j)ush_consumer ( ) ; 



transition disconnectEarly { 
action { 

1 . remove (self) ; 



transition handleEvent { 
action { 

r .handleEvent (data) ; 



transition Tl, T2, T3 , T4 , T5 { 
action { 

raise new OBJECT_NOT_EXIST ( ) ; 




Figure 10. Class ProxyPushConsumerSpec 
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event channel; and has a parameterised marking {<proxy>} which holds a 
reference to a ProxyConsumerList given at instantiation. The place router 
has a parameterised marking {<router>}, where the variable router 
designates a EventChannelRouter. 

Following the scenario of §3.3, the proxy evolves from the state 
imcoimected to the state connected when the operation 
connect jjush supplier is invoked for the first time with a non nil reference 
and is destroyed when the operation disconnect _push_consumer is invoked. 
The ObCS details the behaviour and clarifies the inaccuracies of the original 
specification. When requested, operation connect _push supplier terminates 
in one of the three following ways: 

- a successful connection, transition t5\ 

- a failure raising the exception AlreadyConnected if the proxy is already 
connected, invocation transition t8; 

- a failure if the proxy has already been destroyed by a call to operation 
disconnect _push_consumer. 

When the operation push is invoked, and the proxy is connected, the 
event is first stored locally and the operation terminates (transition tl). The 
EventChannelRouter object is then requested to route the event by a call to 
its operation handleEvent (invocation transition til). If the proxy is not yet 
connected, the operation raises the exception Disconnected (transition tS). 

Once the proxy is destroyed (transition t3) all operations raise the 
CORBA exception OBJECT_NOT_EXIST. When the operation 
disconnect _push_consumer is invoked and the proxy is not yet connected the 
proxy is however destroyed (transition t9). 

4.3.3 Class ProxyPushSupplierExt 

Figure 11, below, shows the class ProxyPushSupplierExtSpec that 
specifies the behaviour of the interface ProxyPushSupplierExt defined in 
Figure 6. Initially, the proxy is not connected to a customer of the event 
channel. An invocation of the operation connect _push_consumer results in 
one of the five following ways: 

1. a successful connection if the parameter of the call is a non nil reference 
(transition t3) and the deposit of the reference of the PushConsumer of the 
customer {Receptor) in place consumer, 

2. a failure raising the exception TypeError if the customer's type does not 
suit the proxy (transition t4)\ 

3. a failure raising exception BAD_PARAM if a nil object reference is given 
(transition tS); 

4. a failure if the proxy is already connected to a customer (transition tS); 

5. a failure if the proxy has already been destroyed (transition t8). 




390 



We have left some indeterminism between point 1 and point 2 that was 
initially contained in the original specification: specific implementations 
must decide on which conditions the exception TypeError will be raised. 



class ProxyPushSupplierExtSpec specifies ProxyPushSupplierExt { 
place unconnected <ProxySupplierList> = {l*<proxy>}; 
place connected <ProxySupplierList , PushConsumer> ; 
place destroyed <>; 
transition connect { 
action { 

l.add(self) ; 



transition disconnect, disconnectEarly { 
action { 

1 . remove (self) ; 



transition push { 
action { 

s .push (data) ; 



transition Tl, T2 , T3 , T4, T5 { 
action { 

raise new OBJECT_NOT_EXIST ( ) ; 




The operation deliver (bottom center), called by the EventChannelRouter 
that created the ProxyPushSupplierExt, will call the push operation of the 



A Formal Specification of the CORE A Event Service 391 

customer that is a consumer of events if the proxy is connected (transition 
t9), or will fail silently raising no exception (transitions tlO and til). 

4.4 Model analysis and tool support 

The use of Petri nets as the formal behavioural notation enables us to 
perform several kinds of analysis on the specifications. We give a short 
overview of the kind properties that are obtained with our tool and the way 
they can be interpreted. In Figure 11, we illustrate the P-invariant for the 
ProxyPushSupplierExtSpec: 

Marking(unconnected) + Marking(connected) + Marking(destroyed) =1. 

It is obtained by mathematical analysis of the Petri net. It means that 
whatever the actions performed by a ProxyPushSupplierExtSpec object, 
there will be one token in mutual exclusion in the three places. From the 
point of view of the specifier, the invariant is interpreted as a desirable 
liveness property. The system has an initial state {unconnected is marked), 
then evolves to an operational state {connected is marked) and finally 
terminates {destroyed is marked): the tool indicates the transitions 
responsible for the flow of tokens from unconnected to connected (transition 
tS) and from connected to destroyed (transition tl). 

The PetShop environment [9] is designed to integrate seamlessly in the 
development life cycle of a CORBA system. It takes into account the 
following steps: 

• Editing of the behavioural specification: the environment includes a 
syntactical editor of Petri nets that supports the editing of the ObCS and 
the declarative part. 

• Generation from IDL: based on the mapping between CO and IDL, a 
skeleton of the behavioural specification is then built. The IDL is 
directly read at runtime from an interface repository. 

• Mathematical analysis of the models: PetShop includes classical 
analysis algorithms that check properties on the ObCS, such as P and 
Tinvariants or liveness properties of the ObCS. 

• Interpretation and debugging of models: in PetShop, each instance of 
a CO class is executed by an interpreter described in [6]. The execution 
is tightly coupled with the editing in order to interactively test the 
behaviour of the model under design without any recompilation. Each 
instance of a CO class is a live CORBA object that can invoke or be 
invoked by any other CORBA object. 

• Distributed execution: PetShop is itself a CORBA server. So it is 
possible from one PetShop to request the instantiation of a class on 
another distant PetShop. 
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• Generation of executable standalone prototypes: It is possible to 
generate standalone prototypes, that can be executed outside the 
environment. 

Using the PetShop environment, we have been able to produce an 
executable formal specification of the CORBA Event Service. The tool 
support has been particularly useful as it provided assistance to detect 
mistakes thanks to invariants analysis and to be more rigorous on the 
expressions used on arc expressions as the tool is unforgiving where a 
human user imderstands the meaning. In turn, the interpretation was very 
important to get a feel of what was happening and allowed us to clarify 
notions like exception handling and to clarify the frontier between concepts 
relating to the formalism and those relating to tooling the formalism. 



5. ONGOING WORK 

Generation of test cases. As our experiments show [18], in the current 
state of industrial practice, it is difficult to rely on informal specifications to 
develop reliable and interoperable CORBA servers. A promising research 
direction consists in combining formal specifications techniques and testing 
techniques to derive functional tests of components under development[ll]. 
We are working at integrating the works already done at LRI and EPFL 
[3;4;12]. The theoretical problems stem from the inherent non-determinism 
in the models, the concurrency of objects, the definition of a parallel test 
driver that emulates the distributed environment, the oracle problem. . . We 
have so far outlined the methodology and hope to reach results in the time 
frame of the SERPICO project. 

Analysis of object-oriented features. We wish to use Petri net analysis 
techniques not only to prove properties on an isolated object, but also to 
analyse constructs specific to object-oriented systems. For example, when 
two IDL interfaces are related through inheritance, some form of behavioural 
inheritance needs to be respected for CO classes that specify these interfaces. 
The work presented in [20] is a useful starting point for us, the most relevant 
notion in the context of CORBA appearing to be the one based on the hiding 
of new methods introduced in subclasses. 



6. CONCLUSION 

The approach presented here is motivated by the momentum gained by 
CORBA as a standard for distributed object systems, and by the evidence 
that some form of abstract behavioural modelling supporting the CORBA 
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object model can be of great help in the development life-cycle of such 
systems. We have shown that our approach is suitable for the specification of 
services having a high degree of complexity and corresponding to real 
problems. The Cooperative Objects formalism allowed us to specify a real 
service due to its expressiveness in describing complex behaviours, 
including concurrency and synchronisation. Not surprisingly, the resulting 
formal specification is complex: this is quite natural, with regards to the 
complexity of the problem to model. However, due to the object-oriented 
nature of the CO notation, individual models (CO classes) remain simple and 
easy to understand (provided the basic notation, high-level Petri nets, is 
known to the specifier). The printed version of the specification is not fair to 
the usability of the CO notation: the PetShop tool, with its ability to execute 
the specification and to provide analysis results, is of great help during the 
construction of the models. Moreover, the tool integrates an elaborate 
debugger that allows to inspect and to change the marking of the places, and 
even the net structure at run-time. It is therefore very easy to correct design 
flaws and to investigate different specification scenarios interactively. 

During the process of building the formal specification of the event 
service, we have detected several incompleteness or ambiguities in the 
COSS document. We wanted to know if the actual available 
implementations of the service had suffered the same problem, and if they 
had solved it in a consistent fashion. The experiment and the tests conducted 
on four implementations of the CORBA Event Service justify the need for 
formalisms that describe the behaviour so that implementers can refer to 
complete, precise and non-ambiguous specifications. The tested vendors' 
implementations, based on the OMG’s specifications, exhibit many 
behavioural incompatibilities. We summarize the main results of our test 
experiments as reported in [18]: 

- Incompatibility with respect to Liskov’s ([14]) substitutability 
principle: if a customers works correctly with one implementation, it may 
well work incorrectly with another implementation because servers do not 
react in the same way to invocations or sequences of invocations; 

- Violations of OMG’s specifications: some implementations do not 
respect explicit specifications. It may result from the complexity of the 
specification (overlooking a point); but also we can point out that the 
OMG does not give a set of minimal test cases to test implementations. 

- No explicit indication of the behaviour of the implementations: the 
specification choices that were made to complete and precise the OMG’s 
specifications are not documented and result in the customers having to 
test the implementation like we did to determine the behaviour of the 
CORBA Event Service they want to use. We therefore produced some 
reverse specifications based on our test campaign. 
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Abstract Software components, arising, typically, in systems’ analysis and design, are 
characterized by a public interface and a private encapsulated state. They persist 
(and evolve) in time, according to some behavioural patterns. This paper is an 
exercise in modeling such components as coalgebras for some kinds of endo- 
functors on Set, capturing both (interface) types and behavioural aspects. The 
construction of component categories, cofibred over the interface space, emerges 
by generalizing the usual notion of a coalgebra morphism. A collection of com- 
position operators as well as a generic notion of bisimilarity, are discussed. 

Keywords: Software component; composition; coalgebra. 

1. INTRODUCTION 

1 . Motivation. Words like component or process are so semantically over- 
loaded that their use is often a risk. What is understood by a software compo- 
nent in this paper is a specification of a state-based module, eventually acting 
as a building block of larger, often distributed, systems. Typically, a component 
encapsulates a number of services through a public interface which provides 
a limited access to the state space. Furthermore, it is intended to persist and 
evolve in time. Components arise, typically, as specification units in systems’ 
analysis and design, namely in the so-called model oriented specification meth- 
ods, such as Vdm [11] or Z [19]. However, it is often difficult to identify and 
reason about their composition mechanisms and underlying behavioural pat- 
terns. This is due firstly to the presence of internal state spaces that cannot be 
discarded and, secondly, to the possibility of interaction proceeding during the 
overall computation. 

This paper suggests coalgebra theory [16, 10, 20] as a suitable framework 
to approach such issues. This relatively new field has been recognized as a 
natural setting to deal with state-based dynamic systems where observations 
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and their patterns seem far more relevant than data construction. In particular, 
coalgebraic methods have been used to approach the semantics of concurrent 
systems [17] and the specification of object oriented programs [15, 8]. 

Although adopting a model-oriented approach to specification, instead of 
the axiomatic setting common to the above mentioned references, our contri- 
bution has a similar motivation. In particular, we discuss how software com- 
ponents can be modeled as coalgebras for a class of functors parametrized by 
a monad which captures particular behaviour paradigms (such as partiality or 
non determinism). The shape of the functor, determined by the application in 
mind, entails a suitable notion of bisimilarity. Finally, some composition op- 
erators are defined in a way which is independent of the chosen behavioural 
paradigm. Such operators have some resemblance with variants of parallel 
composition and renaming found in process algebras (see e.g., [7, 12]). How- 
ever, the presence of (eventually structured) input and output and their trans- 
formations, which plays a minor role on process algebra, is fully handled here. 
Presented as an exercise in coalgebraic modeling, this paper is divided in three 
main sections discussing, respectively, how software components can be spec- 
ified, compared and composed. The notation used and the notion of a monad 
are briefly reviewed in the next two paragraphs. 

2. Notation. Some elementary category theory will be used throughout 
the paper to establish our results. The notation is hopefully clear and standard. 
Set, the category of sets and set-theoretic functions, will be regarded as the 
underlying working universe. We denote the composition of arrows / and g 
by / • 5 . The identity on an object A is denoted by id>i (or simply A if no 
confusion with the object A arises). All binary operators associate to the left. 

The product of two objects A and B is denoted by A x J5 and its sum by 
A B. The left (resp. right) projection of a binary product is denoted by tti 
( resp. 7T2) and the arrow into a binary product induced by the universal property 
of products (usually called the split of / and g) by (/, g). Dually the left (resp. 
right) injection of a binary sum is (resp. 12 ) and the arrow out of a binary sum 
induced by the sum’s universal property is denoted by [/, g] (pronounced either 
f or g). The unique arrow to (resp. from) a final (resp. initial) object 1 (resp. 
0) is denoted by (resp. Finally A a ■ A — > A x A is the diagonal arrow, 
natural in A, given by (id^,id/i). The dual codiagonal ^a ■ A -I- A — > A 
is defined as [id^,id^]. Subscripts will be omitted wherever implicit in the 
context. 

Associativity, commutativity, right and left distributivity are represented by 
the following isomorphisms, natural in A, B and C. a : {A x B) x C — > 
Ax{BxC),s: AxB — > BxA,dr : Cx{A+B) (CxA)+(CxB) and 
dl ; {A-\-B) xC — > (AxC)-\-{BxC). Their inverses are, respectively, a°, s°. 
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dr° and dl°. A useful derived isomorphism is x : {AxB)xC — > {AxC)x B, 
defined as a° • (id^i xs) • a. 

The exponential B^ represents the arrows from A to B, with ap^ ^ ; B^x 
A — > B as the evaluation morphism. The transpose of an arrow f : C x 
A — > B is denoted by / : C — > B^. A partial map from A to JB is written 
as A— 

Functor composition will be denoted by juxtaposition and the identity func- 
tor on Set by Id. For the constant functor on an object A, which maps every 
object to A and every morphism to the identity on A, we will write simply A. 
Given two functors F and G, ct : F G denotes a natural transformation a. 

3. Monads. Monads play an essential role in the paper as a way to encode 
in abstract terms different kinds of behavioural effects. Given a monad B , 
its unit and multiplication are represented by the natural transformations ry : 
Id B and : B B B , respectively. Notice that r] and p act as 
an identity and a multiplication, respectively, and therefore a monad is the 
categorical counterpart of a monoid in Set. Thinking of B as the encapsulation 
of a behavioural effect, rju represents the the minimal such structure whereby 
a value u E U is embedded in B U. On the other hand, p is a flatenning 
operation, providing a way to view a B -effect of a B -effect as still a B -effect. 

The composition of arrows / : I — > B J and g : J — > B O is given by 



g»f = 



This form of composition is associative, with rjA, for each A, acting as an 
identity, originating, for each B , its Kleisli category. 

A monad is strong if it comes equipped with a natural transformation : 
B X — => B (Id X — ), called a right strength verifying some coherence 
conditions [5]. Dually, a left strength is given by Ti^ : — x B => B (— x Id) 
obeying similar conditions. It is well known [13] that in a distributive category 
strength can be defined for every regular functor. A pointwise definition reads 
Trfxic^x) = /i/xx (A m.7y/xA(m, a:)) c. It has the effect of distributing 
the free variable values in the context along the monad. 

The Kleisli composition of and ti gives rise to a correspondence 5r/,j : 
B J X B J — B (/ X J) natural in I and J, given by i,j • tib j j. Or, 
dually, 6ij j = tij j* Tri^sj- Such transformations specify how the monad 
distributes over product. Whenever they coincide, the monad is said to be 
commutative. 
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2. MODELING 

4. Co ALGEBRAS. Think of an endofunctor in Set as the specification of 
an uniform transformation of sets and functions preserving composition and 
identities. It is well known that the signature of a set of constructors of a data 
structure D can be represented as a functor. Furthermore, the data structure 
itself arises as a map t :T D — > D which specifies how values of D are built 
using the available constructors. There are, however, several phenomena in 
programming practice that are hardly definable (or even simply not definable) 
in terms of a complete set of constructors. They do possess an observable be- 
haviour, but their internal configurations remain hidden and should therefore 
be identified if not distinguishable by observation. This is the case not only of 
the state based components we want to consider in this paper, but also of ob- 
jects in object-oriented programming frameworks or of infinite data structures. 
All of them are difficult to express in a purely algebraic way, but find their way 
in the dual paradigm of coalgebra theory. 

The slogan is “reverse the arrows”: a T -coalgebra is simply a map p : 
U — > T U. One way to look at this notion is as a transition structure, of shape 
T, defined on a set U, called the carrier or the state space of p. The shape of 
T expresses the way the state is (partially) accessed, through observers, and, 
on the other hand, how it evolves, through actions. T specifies a signature of 
actions and observers over the carrier of p, but omits its constructors. As a 
consequence equality has to be replaced by bisimilarity (i.e., indistinguishabil- 
ity with respect to the observation structure provided by T) and coinduction 
replaces induction as a proof principle. 

5. Components as coalgebras. Our first concern is precisely the 
shape of T. In fact, different definitions of T give rise to different models for 
components. One that seems to cover a broad range of cases is 

T^ = O'^' X B (- X Oy 

where the sets I, I' and O, O' are, respectively, the input and output observa- 
tion universes which ensure the flow of data. Each T -coalgebra p over carrier 
U is written as split o^), where Op-.UxI' — > O' is the observer, attribute 
or output function, and Op : U x I — > B{U x O) stands for the coalgebra 
action, method or update function. 

On the other hand, T is parametrized by a (strong) monad, B , intended 
to capture a particular behaviour model associated to the temporal evolution 
of components. Such behaviour may be purely deterministic (in which case 
B is instantiated with the identity monad Id) or rather more complex. By an 
appropriate choice for B , different behavioural features might be considered. 
For example. 
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■ Partiality, i.e., the possibility of deadlock, captured by the usual maybe 
monad, B = Id + 1. 

■ Nondeterminism, introduced by the (finite) powerset monad, B = 7^(ld). 

■ Monoidal stamping, with B = Id x M. Notice that, for B to form a 
monad the parameter M should support a monoidal structure to be used 
in the definition of rj and p. 

■ “Metric” nondeterminism capturing situations in which, among the pos- 
sible future evolutions of the component, some are more probable (or 
more secure, or more ...) than others. In fact, isomorphism V{X) = 
X — ^ 1 suggests the extension of the powerset to a mapping expressing a 
richer notion of nondeterminism in which each possible state is assigned 
a confidence level, or probability, leading to X — ^ M (for M a monoid). 
Its refinement to ^(X x M) constitutes a monad. 

By instantiating T -interface parameters with particular sets, one gets more 
specialized notions of a component. Instantiations with 1 are interesting as 
they collapse part of the observation structure. For example, making I' = 
O' = 1, results in T® = B (— x OY , a shape for junctional components. 
A coalgebra of this type is a function p : U — > B{U x oY ■ Given a state 
u € U and an input stimulus i £ I, p computes a B -structure of possible 
responses. Each response is a pair formed by a new state value (representing 
the state evolution) and an output value returned to the process environment. 

Another relevant case - in fact the one focussed in the rest of the paper — 
results from making /' = O = 1, giving rise toT = Ox(B— )^,a shape 
for what could be called object components. What is distinctive of this case 
is output independence wit input. A coalgebra of this type is a split of two 
functions 



(op,o^) -.u ^Ox{BUY 

where Op : U — > O is the state observer (usually called the attribute in 
the object-oriented programming paradigm) and Op : U x I — > B (7 is the 
state update function (usually referred to as the method or the process action). 
Note that, in practice, O is generally a cartesian product rixex different, 
but simultaneously available, observers, whereas I takes the form of a sum 
J2yeY h (state update) non interfering operations. ly is taken as the type of 
the argument of operation y. 

What we have called here junctional and object components, correspond 
to a (monadic generalization) of what is known as, respectively. Mealy and 
Moore machines in automata literature. Other specializations of T are still 
interesting. For example, B (— x O) correspond to purely active components 
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whose evolution is not triggered by any external stimulus, and 2 x (B — )^ to 
(monadic) automata in which the only information available from a state is its 
classification as a final or intermediate one. 

A last ingredient has to be added to our model for components. Since they 
are not required to possess a complete set of constructors, a seed value for the 
state space is required. It represents the initial configuration. A component 
with input I and output O is, then, modeled as a pair {uq € U,p : U — > 
T^o ^)- sequel, denotes functor O x (B — )^. Actually, the seed 

value could be replaced by a set of possible such values (or a correspondent 
predicate) with no extra burden. 

6. Elementary examples. A Stack is a simple example of a component 
with two observers {top and isempty?) and two actions (push and pop). As 
pop is partial, we use the maybe monad in the type of the corresponding coal- 
gebra to force deadlock whenever an illegal pop is performed. Let Ehca set 
and consider the state space is modeled by sequences of E. Then, define 

Stack = {<>e E*, {ost, ast) : E* {{E -fl) x 2) x (E* + l)^+i) 



where the operations have the expected definitions: 

Ost = {top, isempty?) 

where top = Xs . if s =<> then t 2 * else ti(hd s) 
isempty? = Xs . s =<> 

Ost = [push, pop] ’ d\ 
where push = X (s, e) . ti{< e> ^s) 

pop = X (s, *) . if s =<> then L 2 * else l\ (tl s) 

A dummy parameter of pop (of type 1) is made explicit in the component 
interface and represents the trigger for this action. 

Another example of a simple component is the specification of the reactive 
system underlying a Ccs [12] expression, for example, R = a.fd.R + /3.0 -I- 
S-R. In this case the powerset monad is the appropriate choice and the at- 
tribute part may be considered trivial and, therefore, modeled by 1. Let Exp 
denote the set of Ccs expressions and Act = {a, {3,...} the set of actions. Our 
specification is 



RSys = {Re Exp, {oRSys,aRSys) : Exp — >lx V{Exp)^'^) 
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where ORSys =^-Exp and ORSys is given by the following clauses, 

(lRSys{R,0) = {0, i2} 
aRSys{P-R,l3) = {-R} 

o>RSys (e, a) = 0 for all other e G Exp and a G Act 

Both components can be represented in a diagrammatic form, making their 
input and output interfaces explicit. These are drawn, respectively, at the top 
and the bottom of a box: 



E \ Act 



• 




• 


Stack 




RSys 


0 




© 



(E + 1) X 2 1 



7. Morphisms. a component morphism is a coalgebra morphism up to a 
natural transformation Tf^g encoding the interface conversion, determined by 
functions / on the output and g on the input. Technically this amounts to a 
function h between the state spaces making the following diagram to commute 



U 

P 9 

-tB tt -rB V 

' 1,0^ ' I',0'^ ' r,o' ^ 



Furthermore, h has to preserve seeds, i.e., huo = vq, taken uq and vq as the 
seeds for p and q, respectively. 

We need, however, to be more explicit on the definition of Tf^g. For the de- 
terministic case (i.e., B = Id), it is simply t = f x J,foT f : O — > O' and 
g : I' — > I. However, the presence of a non trivial (monadic) behavioural 
structure calls for a broader definition. The basic observation is that each func- 
tion g : I' — > B I induces a function Ug from (B UY to (B Uy given by .»g, 
where • is the Kleisli composition for B . Ug verifies a suitable rephrasing of 
the usual properties of exponentials. First of all, it is natural in U : 



Proof. Let h and g as above. Then (B hV' - Ug = (B h •_)•(_• g) = 
B/i..*g = (.•g)-(B/i._) = Fp-(B/i)^. 



□ 

Furthermore, U- is a contravariant functor from the Kleisli category for B 
to Set, assigning (B (7)^ to an object I and Ug to a Kleisli arrow g : /' — > B I. 
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Clearly, {7;,^ = —mg = — = id (0 y)/ . On the other hand, 
is a direct corollary of the following more general law. 

8. Lemma. For / : C/ — > [/' and g : I' ^ {B UY , define fg : (B UY — >• 
(B U'Y' by 

fg ^ {Bff ■m)g = B/._.5 

Now, let U" and g' : I" (B Uf ■ Then • fg = (/' • f)g,g,. 

Proof. 

= (B/')-((B/)._.3).5' 

= {Bf'-f)-..{g.g') 

— if • f)g»g' 



□ 



9. Categories of components. Sununing up the previous discussion, 
a morphism between B -components can be presented as a pair {h, Tf^g), with 
/ : O — > O', g : I' — > B I, where h : U — > V is seed-preserving and 
makes the diagram in §7 to commute. Ty ^ is the natural transformation whose 
U component is {Tf^g)u = fxUg with Ug defined wit the Kleisli composition 
for B. Given two such arrows (h,Tj^g) and {h',Tf>^g>), their composition is 
{h' • h, Tfi.f^gugi). Finally identities are defined as {idu, nAo,m)- Components 
and component morphisms form, therefore, a category Sr. 

A crucial point is to ensure that the proposed definition for Tf^g subsumes 
the standard case in which the monadic effect is not present. Note that, for 
the maybe monad, monadic g is just the classifier (or “totalizer”) of a partial 
map g' : I' ^ I. If g' is itself total then its classifier g satisfies the equation 
9 = I'l ’ g' and Ug coincides with {U -f- 1)^ . This is indeed the case for 
the other monads considered above. In fact, a non monadic input morphism 
always emerges as a special case of a monadic one. That is to say, a total map 
for the maybe monad, an entire and simple relation for the powerset, etc. The 
following lemma proves this for the general case. 

10. Lemma Let g' : I' — )■ I and define g = rji • g'. Then Ug = (B U)^' . 
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Proof. Let (j ) : I — > B U. Then 
UgCt> 

= 4>*g 
= 9') 

= • B </)•??/• g' 

= g-’VBu ’ 4>- 9 ' 
= (B uy' 4> 



{ by definition } 
{ g is non-monadic } 
{ • definition } 
{ naturality of } 
{ monad identities } 
{ by definition } 



□ 



3. COMPARING 

11. Bisimulation. When comparing software components, one intuitively 
identifies models which, being non isomorphic at the data level, behave in a 
similar way “as far as we can see”. Furthermore this tends to be the key ingre- 
dient in specifications of distributed systems whose “observational contents” 
(or parts thereof) are shared by different observers. 

In [14, 12] the notion of bisimulation was introduced in process calculi to 
capture this kind of observational equivalence. Later [1] gave a categorical 
definition of bisimulation which applies to arbitrary coalgebras (i.e., bisimu- 
lation “acquired a shape”). Such a notion of T -bisimulation, for a functor T, 
is defined as a span {R, ri,r 2 ) whose legs lift to T-coalgebra morphisms, or, 
in other words, such that there is a T-coalgebra p : R — > T R making the 
diagram below (on the left hand side) to conunute. 
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In Set this can be rephrased in terms of a relation whose projections lift to T- 
coalgebra morphisms. The diagram on the right hand side is the corresponding 
instantiation for the functor underlying our model for components. 

12. Proof rules. Let p = {op,a^). A simple calculation yields 

p-TTl 

= (O X (B 7Ti)^) • p { required } 

= (O X (Btti)'^) • {op,a^) { by definition } 

= {op, (B niY • a^) { X -absorption } 

= (op, B 7Ti • Up) { exponential-absorption } 



and, similarly, q - 1^2 — (op, B 7T2 • Op) . A direct consequence of these equali- 
ties is the fact that, for any (n, v) £U xV, the following equations hold: 

Op {u, v) = OpU = OqV 
B'n\-ap{u,v) = a^u 
B 7T2 • Op {u, v) = a^v 

Finally, we may rephrase such results as a proof rule for bisimulation, whose 
shape depends on the adopted behaviour monad. For the deterministic case 
= Id) this yields 

(u,v) E R OpU = OqV A {up {u,i),aq (v,i)) G R 

For partial components B = Id -|- 1), on the other hand, 

{u, v) G R OpU = OqV A Vi G / 

( {ap{u,i) = aq{v,i) = {2,*)) 

V 

(op {u, i) = (1, u') A Oq {v, i) = (1, v') A {u', v') G R)) 

Finally, for the non deterministic case (i.e., B = P(ld)) the proof rule resem- 
bles the definition of bisimulation for classical labelled transition systems, 

{u, v) G R OpU = OqV 

A Vi G / 

( ^u'&ap {u,i)^v'Qaq (v,i) ^ R 

A 

( '^v' £aq {v,i)^u'€a,p {u,i) ^ ) G -^) 
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Notice that if p and q both denote the final coalgebra, then morphisms tti and 
7T2 coincide (by finality), p is an isomorphism and, therefore, bisimulation boils 
down to equality. 

13. Definition. Letp and q be components over the same interface (O, I) 
with uo G and uq G F as seeds, respectively. They are said to be bisimilar, 
written p =Tq / Q (abbv. p = q)ifi there is a T o, /-bisimulation containing the 
pair (uo,t»o}- 



14. ... UP TO. Now how does interface data interfere with the definition 
of bisimulation? Moreover, what is the effect of “monadic” input morphisms 
in defining bisimulation, and, therefore, relating component models? The first 
question leads to the definition of bisimulation up to Tj^g. The definition is 
well-behaved in the sense that standard results can still be rephrased in this 
setting. In particular, we prove in [3] that bisimulation is preserved by Sr- 
arrows and, moreover, the graph of a morphism {h, Tf^g) is a bisimulation up 
to Tf^g, where, 

15. Definition. Let p and q be components over {0,1) and {O', I'), 

respectively, and Tf^g : T/,o => be a natural transformation. Thenp 

and q are said to be bisimilar up to r iff 

p=rq ^ {Tf^g • p) =Tj, o> Q 



4. COMPOSING 

In this section we move on to the introduction of some basic operators for 
composing components in category Sr. First, however, we need to define a 
twin category of interface spaces for components. 

16. Definition. For each behaviour monad B , the interface category Intfs 
(abbv. Intf), has pairs of sets {O, I) as objects and pairs of functions as arrows. 
In particular, a morphism I : {0,1} — > {O', I') is defined as {f,g), with 
/ : O — > O' and g : I' — > B I. Composition and identities are pointwise: 
inherited from Set in the first component and from the Kleisli category for B 
in the second. 

17. Wrapping. A basic operation upon components is interface wrapping in 
order, for example, to restrict its use or to pre- or post- process a particular pa- 
rameter. In classical process algebra this corresponds to relabelling. However, 
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the explicit consideration of input and output types in the model presented in 
this paper, turns it into a much more powerful operation. As illustrated below, 
it includes restriction as a particular case. 

The definition of wrapping builds on the fundamental observation that Sr 
is cofibred over Intf (lemma 18). A cofibration is a functor L : Sr — > Intf 
providing co-cartesian liftings of every Intf morphism I : {0,1) — > {O', I') 
originated in the L image of each Sr-object. This means, in our context, that 
given a component p each interface morphism I : Lp — > {O', I') can be lifted 
(or extended) to a component morphism l\ : p — > q, such that Lq = {O', I') 
in a canonical way. 

Given an interface morphism I : {O, I) — > {O', I') and a component p 
with interface {O, I), as above, we denote p wrapped by I by hp or, simply, 
p[(]. In the Stack example, for instance, one has O = {E + 1) y. 2 and 
I = E + 1. Then, 



SimplerStack = Stack [{n2,r]E+i)] 

denotes a stack with no top attribute (O' = 2, /' = I). Further restricting the 
use of both top and pop yields 



StrangeStack = Stack [(7T2,77i • ii)] 



Often the input component of the wrapping morphism is a non monadic arrow, 
made monadic by composition with the monad unit. This is the case in the 
examples above. In the sequel we omit this composition for improved read- 
ability, if types are clear from the context. Furthermore, we write p[f, g] as an 
alternative notation to p[{f, g)]. 

18. Lemma. The functor L ; Sr — > Intf defined by 

l{uo €U,p:U Ox {BU)^) = {0,1) 

^{h,rf,g) = {f,g) 



is a cofibration. 

Proof. Consider p = (uq € U,p : U — O x (B UY) and let {f,g) : Lp — > 
{O' , I') a morphism in Intf (see diagram below). We claim that its cocartesian 
lifting is (idf/,T/,g) : {uq,p) — >• {uq, (idt/, r/,p)p). 
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Sr 

L 

Intf 



(uo, 




{vo,t) 




Let t = {vq C V,t : V — > O" x (BV)^"} be another component and 
(h,Tfi^gr) : {uq,p) — > {vo,t) be an Sr-morphism. Suppose that {f',g') ■ 
(0,1) — > {0",I”) factorizes over {f,g) in Intf through {f",g"). Therefore 
composition in Intf yields f" • f = f and g • g" = g' . We may, then, close 
the upper diagram, in a unique way, with (h, Tfu gii). In fact, 

{h,Tf"^g") • (idf/,r/,g) 

= {h,f"xUgn).{idu,fxUg) 

= {h,U"'f)xUg.g.,) 

= (hj'xUg.) 

= {h,rf',g>) 

□ 



{ by definition } 
{ by lemma 8 } 
{ by factorization in Intf } 
{ by definition } 



19. Pipelining. Another basic construction on components is pipelining, 
which corresponds to a kind of sequential composition. It is associative but 
only up to isomorphism, as the presence of internal state precludes most prop- 
erties to hold up to equality. 

Letp = {uo €. U, p : U — > Z x (B UY) and q = {vq eV, q :V — > O x 
(B V)^) stand for two component models. A pipe is formed by placing them 
side by side and connecting the output of p to the input of q. The composed 
system is p-,q — {{uq,vo) E U x V, p q : U x V — >• O x (B (17 x V)Y) 
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where p',q = {op.q, ap.q) is given by 

TTo On 

Op.q = UxV V O 

ap.g = (UxV)xI (U X I) xV BUxV B(U xV) 
BB([/xV) B(UxV) 



where 



aux = U xV > (UxV)xZ U x {V x Z) 

U xBV — ^ B{U xV) 



20. Parallel composition. Unlike, e.g., the cartesian product of data 
structures, components’ parallel composition is not described by an universal 
construction. We have proceeded experimentally by identifying some tensors 
and studying their properties. We shall consider here three such structures. In 
all of them the composed state space is the cartesian product of the component 
states. They differ, however, on the allowed interaction patterns. 

In the sequel let p = {uq E U, p : U — > O x (B UY) and q = {vq E 
V, q :V — > P X (B F)*^) stand for two component models. 

The first two tensor products are p ffl g : C/ x F — > {O x R) x {B{U x 
V)Y+'^ and p K g : U X F — > {O x R) x {B{U x V)Y^^ . p ffl g behaves 
either as p or g depending on input, and corresponds to what is called external 
choice in process calculi. On the other hand, p S g is a synchronous product; 
both processes are executed simultaneously when triggered by a pair of input 
values. A more “liberal” interpretation of parallel composition is given by 
another tensor product p El q-.UxV — > {O x R) x (B {U x F))^®'^, where 
X El F is given by the coproduct X + Y + X xY. The intuition is that, 
by putting both components side by side one gets an (observable) increase of 
behaviour: not only the individual observers and actions of both processes are 
available, but also there is the possibility of activating them concurrently (the 
disjointness of the two state spaces avoiding interference). 

Their definition coincides on the observers 



OpXOq 

— XJ 'K V ^ O R 
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but does differ on actions. Therefore, 

Opffl? = (C/ X F) X (/ + J) {UxV)xI+{UxV)xJ 

{U X I) xV + U X {V X J) ""1^ BU xV + U xBV 

B{U xV) + B{U xV) B{U xV) 



ttpEig = [U X V) X [I X J) 5- (U X I) X {V X J) 



BUxBV B (C/ X V) 



and 



apffl, = {UxV)x{I + J + IxJ) 

^ (J7 X F) X (/ + J) + (?7 X F) X (/ X J) 

B (?7 X F) 

Moreover, units for ffl and s coincide: in both cases take the component 
with empty input and the singleton state space, i.e., 

/ffl = Iffl = (* € 1, (idi,idi) : 1 ^ 1 X (Bl)®) 

The unit for B is 6 1, (idi, rji) : 1 — > 1 x (B 1)^). Note that the 

use of Sr or Si in the definition of S is irrelevant for B a commutative monad. 
On the other hand, choosing B = Id* leads to two alternative versions of syn- 
chronous product. Commutativity thus seems to be a reasonable requirement 
to impose on behaviour monads. 

21. Hook. Component interaction is not captured by any of the tensor 
products above. However the kind of plugging done in sequential composition 
may be generalized to a hook operation connecting some input to some output 
points. 

Depending on the shape of the input interface, we consider an effective or a 
delayed hook. The first case assumes the argument is modeled by a coalgebra 
p : U — > (O X Z) X {BUy^^ . Define (p)z as a coalgebra with the same 
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signature and observer which feeds back part of the output as follows: 
^{p)z = U X {I + Z) B U BBC/ — ^ B U 



where 



(id,7r2*Op) id XC.9 / -w 

aux = U ^ U X Z ^ U X {I + Z) B U 

A delayed hook applies to cases in which the required input is a tuple whose 
second component comes from the (previous) state. Note that the common 
parameter becomes hidden. Formally, letp : (7 — )■ {O x Z) x {U + . 

Define zip) as 



®z(p) 



= TTl • Op 

= Uxl 



(id,(7r2, Op -TTi)) 



X (/X Z)-^BC/ 



22. Example. In order to illustrate the use of the connectives just in- 
troduced, consider a distributed querying system in which a question (modeled 
by a type Quest) is simultaneously placed to several independent data sources, 
each of which supplies a possible answer (of type A). A special component 
acts as an answer collector, merging all the answers produced and comput- 
ing a final result by means of some pre-defined algorithm. Let us start with 
two data sources (the n-ary case is dealt similarly) DSour\ and DSour2 as 
well as a concentrator DSink acting as a data sink. Note that DSour\ and 
DSouv2 may have different definitions and need not to be deterministic. A 
typical choice for B in this example would be B =V{— x R), where R is the 
confidence level assigned to a given answer. 

Quest 



DSour2 

e— 

A 

We begin by constmcting the synchronous product DSour\^DSour2 with 
input Quest x Quest and output A x A. As the same question is to be placed 
simultaneously to both data sources, this input has to be reduced by wrapping 
the combined process with the diagonal function, i.e., 

DS = {DSouri S DSour2)[id, A] 




Quest 



DSouri 

— e— 

A 
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Next DS is composed with DSink via ffl and the output of the former fed back 
into the later, through a double application of hook. For this to be possible, 
however, the input of DSink has to be expanded to a coproduct of A, which is 
achieved by wrapping with the appropriate codiagonal 

SS = DSink [id, V] 

Some additional wiring is required to apply the hook operator: the output in- 
terface of DS ffl SS is {Ax A) X Inf and, consequently has to be changed to 
Inf X (j4 X by wrapping with the s isomorphism. The result is pictured in 
the diagram below. 




Ax A 

The aggregated system is, therefore, given by 

QuS = ((£)5ffl55)[id,s])A,A 

Finally, the intermediate answers are hidden from the environment, yielding 
the final querying system as a new component pictured as follows 



Quest 



Qu5[ii,Tri] 



Inf 



23. Functions. Functional components, i.e., components representing pure 
functions, are encoded in Sr by output mirror. Let (f) : A — > B. Its encoding 
as an Sr object is 



= (6g5, (idB,J7B-<^'7T2)) 
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whose coalgebra is of type B — > B x (B 

Note, however, that sequential composition in Sr does not specialize to the 
usual functional composition. The reason is that the state space in cannot 
be discarded. Moreover, the need to choose a seed value makes the repre- 
sentation of 4 > not unique. for any <p, satisfies, however, an almost seed 
irrelevance property; given two encodings of (f> with different seeds, for ex- 
ample, Pi = (bi,p) and p2 = {b2,p) (p = {idB,T)B • 4>'T^2)\ they become 
bisimilar in the step following the initial one. 

To see this we have first to formalize a weaker notion of bisimilarity, which 
could be called next step bisimilarity. The intuition is that two components 
p and q are in such a relation if each pair of successor states of p and q is 
contained in a T/,o-bisimulation. Given a T/,o coalgebra p, over a state space 
U, and a state u G 17 the (possibly empty) set of successors of u is denoted by 
•p ^{u} and given by (un)lifting the set 

{a(i)| i G I A a = n2 •p(u)} 

wrt functor B . Technically, this computation is left adjoint to the predicate 
lifting introduced in [6], for (extended) polynomial functors (the whole topic 
is addressed in [9] in the broader context of modal languages induced by coal- 
gebras). Omitting, for the sake of brevity, the calculational details, we just 
present *p for the two familiar cases of the maybe and the powerset monads. 

={^ € U\ LlX G {(7T2 •p(u))(i)l i S -f}} 

-p(^^))(OI i e /} 

The announced definition is as follows: 

24. Definition. Let p and q be components over the same interface ( 0 , 1 ) 
and behaviour monad B , with uq and vq as seeds, respectively. They are said 
to be next step bisimilar (written p =, q) iff 

•p {«o) = »?{»o}=0 
V 

(i^o) ■ i^^P) ~ (^>9) 

A 

(uo) (uo) ■ i^iP) ~ (^) 9 )) 



25. Lemma. Let 0 i and (f>2 be two encodings of a function 4 > : A — B 
over different seeds 61 and 62- Then (f>i =, 4 > 2 . 
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Proof. It is enough to show that the sets of successor states in both cases coin- 
cide. If they are both empty we are done; otherwise take the identity relation 
to trivially witness all the required bisimulations. Denoting, as in [9], the un- 
lifting of a predicate wrt a functor Bby(— )b :'P(B— ) — > 7 ^(— ), a simple 
calculation yields 

= ({«a| o € ^ A a = (7T2 • <^i)6i})b 

— {{aa\ae A A a = (7T2 • (idB,??B * • 7T2))6 i })b 

= ({aa| aC A A a = {t]b • • 7T2) &i})b 

= ({(r?B • </>• 7T2) (6i,a)| a € ^})b 

= {{{VB ’<p)a\ae A})b 
= ({(t?b • 7T2) (62, a) I a e A})b 



□ 



5. CONCLUDING REMARKS 

26. Related and Future Work. This paper presented a coalgebraic 
model for software components and defined some core operators of a com- 
ponent algebra. Components and component morphisms are shown to form 
a category Sr. This definition allows for monadic input morphisms to be ab- 
sorbed by the component behavioural model. Furthermore, we prove that Sr is 
cofibred over the interfaces. 

Further properties of the operators as well as alternatives to the basic model 
are discussed in [3]. For example, a simple extension captures the presence of 
internal actions which allow the component to evolve without being triggered 
by the environment. 

Complementary research, described in [2], concerns the prototyping of com- 
ponent’s behaviours in the non strict functional language Charity [4, 18], by 
computing the anamorphic image of their seeds. In fact, the behaviour of a 
component abstracts over all internal states. For a T® component, this is rep- 
resented (or encapsulated) in the image of its seed under the unique arrow (the 
anamorphism) from p to the T® q final coalgebra. The actual way in which the 
anamorphism is computed (and the behaviour revealed) resorts to lazy evalua- 
tion. In each step, activation of a new continuation structure is returned upon 
which experimentation proceeds. 

A current research topic concerns the refinement of this kind of coalgebras 
with structured input and output, which involves a weaker notion of coalge- 
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bra morphism. In fact, not one, but several notions of refinement arise in a 
construction which is, again, parametric on the behaviour monad. 
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